- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 May 2016 19:31:24 -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.
=========================================
Grid
----
- RESOLVED: The grid-template and grid-gap properties have no
effect on a sub-grid
- Tentatively the group resolved that auto-repeat should be
invalid despite existing implementations. And remove the
grammar that allows repeat() for columns as it was an accident.
- If there are no objections on the mailing list before the
next telecon, the group will formally resolve.
- TabAtkins asked anyone interested in the algorithm to review
section 12.1, issue #8
- RESOLVED: Take the clamping behavior for error cases on subgrid
where items are outside the subgrid (issue 4).
What level should break-spaces go to
------------------------------------
- RESOLVED: Add overflow-wrap: break-spaces to level 3
Overflow
--------
- TabAtkins brought to the group that the spec and implementations
disagree on behavior for when a scroll container with overflow
auto or scroll and padding on all sides: does the padding on
the end edges get included in scrollable area?
- In the block direction some implementations do show padding
and it was generally agreed that that is the author
expectation.
- There was a lot of concern in changes breaking web compat,
especially in the inline direction as no specs do that.
- TabAtkins proposed amending the spec to say that padding
should be respected in the block direction and noting the
issue around the inline direction which would encourage
people to note breaking behavior around that or make test
implementations allowing it.
- Conversation will continue on the mailing list.
- RESOLVED: Publish a new WD for overflow
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016May/0213.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Myles Maxfield
Michael Miller
Anton Prowse
François Remy
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Steve Zilles
Regrets:
Chris Lilley
Edward O'Connor
Lea Verou
Scribe: dael
Grid
====
Rossen: Let's get started.
Rossen: First agenda item, any additional items?
[silence]
Reduced Subgrid Proposal - 1-axis subgrid
-----------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016May/0196.html
TabAtkins: So we roughly discussed it...
TabAtkins: We discussed it at the F2F. This is...a somewhat open
question at the F2F is subgrid doesn't pay attention to
grid-template-rows and grid-template-columns. We may in
the future want to do one axis subgrid. The question
was if we should have that future switch be existent on
a non-none grid-template-rows.
TabAtkins: After discussion we decided the idea that we could
depend on that being a safe upgrade path in the future
was not realistic. We'd see a bunch of pages broken by
this. So we decided that if we do 1 axis in the future
we'll do it through new syntax. New grammar or a
display value that's very distinguishable.
TabAtkins: Therefore the properties that grid doesn't pay
attention to do do nothing.
TabAtkins: That's the thing we're doing and we thought we should
get approval.
<frremy> TabAtkins fantasai: looks good to me
fantasai: The case that would change behavior is if someone set
grid-template-row and -column we'd treat it as a massive
grid. If you set one it wouldn't be a subgrid, but in
the future it would be a 1 axis subgrid and you would
get different behavior. dholbert thought it would be a
dangerous upgrade path that we shouldn't try and do.
jensimmons: Sounds good to me. I have a question, you said if I
declare subgrid and then define grid-template-rows and
areas I've turned my display into a grid?
fantasai: That's what we considered. Right now it would ignore
your declarations.
jensimmons: As it's bad code.
fantasai: It would be like you said col-width on a table.
jensimmons: It sounds good to me. It makes sense to me.
Rossen: Okay. Any other opinions?
<tantek> this makes sense to me too. thanks TabAtkins fantasai for
exploring this deeper.
Rossen: I'm personally okay with that. It is a little hackier than
I want, but given the restrictions it's the best we can
come up with at the moment.
Rossen: Do you want a resolution?
TabAtkins: Yes.
Rossen: Anyone objecting? Can you summarize?
TabAtkins: The grid-template and grid-gap properties have no
effect on a sub-grid.
Rossen: If display property contains subgrid those are ignored.
TabAtkins: Yes.
Rossen: Okay, any objections?
RESOLVED: The grid-template and grid-gap properties have no effect
on a sub-grid
Auto-repeat inside grid-template shorthand
------------------------------------------
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016May/0193.html
<fantasai> https://drafts.csswg.org/css-grid/#explicit-grid-shorthand
TabAtkins: We...the grid-template shorthand, one grammar was the
full "let's draw ASCII" declaration. So you can draw
with ASCII and on side and bottom declare lengths and
widths. In one place it claims you can use repeat()
which is an accident. All implementations allow repeat()
for the rows as well. This is weird. The point of this
is to give you a good visual representation of the grid.
The grammar is set for 1 to 1 physical relationship.
TabAtkins: Using repeat() in this breaks that. You don't have 1 to
1 between a track and its size.
TabAtkins: It doesn't make sense because the template has no
intrinsic relation to the grid at the end.
TabAtkins: So 1) auto-repeat should be invalid despite existing
implementations. And remove the grammar that allows
repeat() for columns as it was an accident.
Rossen: Do we have a FF implementor working on this?
* tantek would have to check with dholbert
* tantek is not sure
Rossen: Was this discussed with igalia?
TabAtkins: We did with Manuel in the thread.
dbaron: I'm on but don't know enough; ask dholbert or mats.
Rossen: It would be great to gather opinions a little further.
<fantasai> dholbert:
https://lists.w3.org/Archives/Public/www-style/2016May/0193.html ?
Rossen: Basically, I'd like to get more implementor opinions. I'm
fine with it on our side. I'm not sure if that's true for
others.
Rossen: If you're putting this on the table I'm assuming Blink is
fine.
TabAtkins: Yes. They'll be fine.
fantasai: It's just a parsing issue.
Rossen: So we can tentatively resolve and wait for dholbert or
anyone else from webkit to comment and we'll go from there.
TabAtkins: That would be good.
Tentative resolution: auto-repeat should be invalid despite
existing implementations. And remove the grammar that allows
repeat() for columns as it was an accident.
Rossen: We'll revisit next week and if there's no replies on the
ML we'll call it resolved.
Heuristics issue
----------------
<Rossen> https://drafts.csswg.org/css-grid/#algo-overview
TabAtkins: I'm getting the spec being jumpy...it's 12.1
TabAtkins: This is hard to explain. I'll go over and let people
review.
TabAtkins: When doing grid sizing the algorithm generally assumes
everything is in the same writing mode. So inline size
calculates first than block size. That's not always
true, you sometimes have orthogonal flows. In those
cases we have to give an estimate on the height area.
Then, because the estimate was almost certainly wrong,
we do a second pass using the updated info.
TabAtkins: In theory this can keep happening until we stabilize,
but the IE group said we can do this in 2 passes and we
believe them so that's what we do.
TabAtkins: The problem is the original estimate was quite bad. If
any one row is a min-content or a flex or an auto we
consider it to be infinite for the first run.
Orthogonal flows can deal with infinite. But it's
almost guaranteed wrong on the first pass.
TabAtkins: fantasai realized we can do better in a lot of cases.
If it only spans a min-content or max-content it will
be at least that size. The proposal is to change the
heuristic to take into account better estimates listed
in issue 8.
TabAtkins: This needs to be thought about in someone's leisure
time. dholbert, fantasai, and I agree. This should
always be at least as accurate and sometimes more. It
should give us just as good or better layout and maybe
remove the second pass.
TabAtkins: No need to resolve today, but if someone outside of FF
can review it would help.
Rossen: My initial reaction was favorable. I'll send comments to
the ML and we'll have a more definitive resolution. In the
beginning when this was worked on for us treating those as
undefined was the most straightforward, but there will be
layout that would be unfavorable on the final result.
Rossen: Let me digest and we'll comment back.
TabAtkins: Thank you.
Error-handling preferences issue
--------------------------------
<Rossen> https://drafts.csswg.org/css-grid/#issue-9191c5b6
TabAtkins: It's issue 4 in the spec in section 8.
TabAtkins: Item e.
TabAtkins: The question is, subgrids do not have an implicit grid.
They get the grid you tell them to have.
TabAtkins: This is different from normal where you can position
outside the declared columns and we'll add them.
fantasai: We also create implicit tracks. subgrid won't grow to
accommodate.
TabAtkins: So how do we treat things when they try and go outside?
Current spec is we use the clamping behavior. The other
possibility is we consider this an error case and make
it span the whole grid.
TabAtkins: We don't have a strong opinion either way. Whatever the
WG wants we'll keep in the spec.
Rossen: Opinions? I don't have a strong one. spanning the entire
grid would be obvious and somewhat weird. I don't recall
anything similar.
Rossen: Anyone have an opinion?
Rossen: Or does TabAtkins 's proposal make sense?
jensimmons: I want to have an opinion, but I don't think I
understand what the difference would be yet.
Rossen: TabAtkins can you give an example?
TabAtkins: You've got a subgird that's 2 column and 2 row span.
You have an item in the subgrid positioned in column 3,
row 1.
TabAtkins: Clamping proposal shifts its inward to row 1 column 2.
TabAtkins: Span the whole subgrid makes it fill the 2 x 2 space.
rachelandrew: Would the difference affect content flowed
automatically?
rachelandrew: I prefer the clamping thing.
<gsnedders> I think I prefer the clamping thing too, FYI.
<jensimmons> rachelandrew: \o/ So glad you are here.
bradk: I prefer the clamping, it's more author friendly.
Rossen: Sounds like people are inclined to have subtle hints.
TabAtkins: So we can resolve on that?
Rossen: Objections to resolving on clamping behavior for error
cases on subgrid where items are outside the subgrid?
RESOLVED: Take the clamping behavior for error cases on subgrid
where items are outside the subgrid (issue 4)
Rossen: I did want to say welcome Rachel
<tantek> yes! welcome Rachel!
<dauwhe> welcome Rachel!!
What level should break-spaces go to
====================================
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016May/0134.html
Florian: We resolved to add break-spaces value to overflow-wrap,
but we didn't resolve if this was 3 or 4.
Florian: I made the pull on level 3 because 4 is earlier in
development. More important it was because some browsers
do have the behavior and I'd like to add the switch so
that they can keep the behavior. But if we're trying to
lock down level 4 makes sense. koji thought 4, I thought
3. What does the group think?
Rossen: I'd prefer 4 given how long css-text 3 has been out there
we should be locking down. Adding more things that will be
moved sounds like a step backwards.
fantasai: I don't think I have a strong opinion.
* glazou totally agrees with Rossen
Rossen: Do you feel this would slow level 3 down?
fantasai: I doubt it. It's a pretty localized fix.
fantasai: It's only adding a keyword and the definition. I could
go either way.
Florian: I think there's a limited chance to slow it. There's 1.5
impl of the behavior. FF has it fully and Edge partly. So
if we don't put it in L3 there's a risk the browsers will
lose the behavior. If it's in L3 they'll have to add the
other behavior, but won't have to remove what they have.
Rossen: I doubt we'll lose anything in impl effort. As long as
we're not slowing level 3 I'm fine with this going into it.
Slowdown was my only reservation.
<glazou> CSS 3 Text has been on the REC track since 1999...
Rossen: To glazou point its been 17 years.
Rossen: So any objections to adding this to level 3?
Rossen: I'm looking to editors and people working on the draft.
Florian: koji isn't on the call. I don't think he objected, he was
just wondering.
RESOLVED: Add overflow-wrap: break-spaces to level 3
Overflow
========
Clarify padding-bottom
----------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/129
TabAtkins: The question is, if you have a scroll container with
overflow auto or scroll and it has padding on all
sides, does the padding on the end edges get included
in scrollable area.
TabAtkins: The overflow spec says both. Implementations disagree.
What should we go for?
TabAtkins: I have some implementation on my blog that relies on
Chrome letting you have it on the bottom.
TabAtkins: This lets you do something like an overscroll.
TabAtkins: But I don't know why browsers have gotten rid of the
padding.
Florian: To go further, if we have hanging punctuation that puts
an overflow into the padding so I'd like to keep the
inline padding.
<myles> i think you can see it well at
https://bug748518.bmoattachments.org/attachment.cgi?id=618078
<fantasai> testcase
https://bug748518.bmoattachments.org/attachment.cgi?id=618078
Rossen: Can you clarify, are we talking about...you have a box A
that has overflow scroll
Rossen: That box has fixed width and height and has adding 5em
Rossen: Is it the padding of that box?
TabAtkins: Yeah. If you have enough content to overflow all
browsers but Chrome and webkit ignore block end. All
ignore inline.
Rossen: That's odd because it's on the box. If there's content
that overflows, it's the content that overflows.
dbaron: This is why browsers implement it that way. The spec is
clear that the padding doesn't move when you overflow. The
question is what is being scrolled by the scrollbar
Rossen: Content. Not the box, the box is static.
TabAtkins: The posision of the box doesn't change.
Rossen: If you have an inset shadow when you scroll you don't
suppose it will scroll.
fantasai: No one is suggesting that.
fantasai: Padding space is not visible.
Rossen: Yes.
Rossen: Unless you make it
<gregwhitworth> testcase: http://jsbin.com/cujojereki/edit?html,css,output
<Florian> Demo in the inline direction here: http://jsbin.com/tadiha
fantasai: The backdrop of the box should be drawn as if it has no
content. It shouldn't affect box decoration. Where are
you positioning the content in respect to the edges of
the scrollable area. In the top-left corner there's
space left for the padding and that's part of the
scrollable area. Then when you scroll to bottom-left
it's not symmetric. The padding that's there is clipped.
fantasai: You cannot scroll things such that it would sit if the
padding existed.
fantasai: It makes the scrollable area feel tight because there's
no breathing space.
<TabAtkins> It's weird as heck to argue that the padding space
isn't scrolled; the scrollable box isn't shrunk inward
by the amount of padding.
Rossen: Let's go through the queue.
dbaron: I'm okay with having something...assuming it's webcompat
which it is not clear that it is...I'm okay with putting
something in that produces the results authors expect. We
should be clear its magic on a broken model. We're doing
scrollable areas via overflow and that's not right. On the
premise you do that padding is part of it.
dbaron: I'm fine with adding a rule, but don't try and do it in a
way that pretends it's anything other than a hack.
TabAtkins: The reason people expect it is it doesn't feel like a
hack.
fantasai: He's saying that's not the spec model.
fantasai: You can see this is the way it works. Suppose there's a
box inside a scroller and the box is the size of the
scroller. Suppose it overflows and you don't get a
scroll because you can see it.
TabAtkins: I strongly disagree and that's not chrome in the block
axis.
TabAtkins: If you have 100 box, 80 content and 50 padding you get
a scroller. And that's intentional.
<bradk> It's weird that the top of the content fits under the top
padding, but the bottom of the content doesn't fit above
the bottom padding.
<gregwhitworth> I provided a block example above showing
Blink/Webkit behavior
myles: Chrome and webkit have been shipping this block direction
for years so it's web compat.
dbaron: We don't know on inline.
myles: That was mainly my point. That authors will expect the
padding when you scroll down and it add symmetry that's
powerful.
Rossen: That would be a complete change in our model. I'm not sure
we can commit.
Rossen: I also want to echo the concern on web compat
Florian: How does your model do things like ink overflow into your
padding? Hanging punctuation is ink overflow.
fantasai: That's an open issue
Florian: Wasn't there other stuff?
Rossen: We need to understand the compat issue. The box model is
fairly well defined in CSS 2.1 and scrollbars were built
on top. You can read the spec in both ways. I don't
disagree on author expectation, but I would not resolve on
a drastic behavior change without understand on what the
web compat effect it.
TabAtkins: dbaron was trying to say something on webcompat and he
got covered.
Rossen: If we go by that then we need to spec all kind of other
quirks.
TabAtkins: No. You asked what is webcompat and we have an argument
this is.
dbaron: I will not believe without proof that it's webcompat in
inline.
myles: It sounds like two issues, inline and block.
tantek: I'm going to underscore what dbaron is saying. From having
struggled with this we did reach a point of interop on the
scrolling box padding behavior on desktop browsers. So I'd
assume there are web compat issues on desktop. I'm not
sure on mobile browsers and content. I would guess similar.
Unless there's arguments from evidence I'm not buying it.
myles: As I said, maybe we should discuss inline and block
separately.
Rossen: We don't usually for box model
myles: One might be web compat, the other may not.
<fantasai> tantek: load
https://bug748518.bmoattachments.org/attachment.cgi?id=618078 in
Chrome
<fantasai> tantek: There's youre existence proof
Florian: Small point, but even though I see that having the same
for a long time tends to invite web compat, but I'm
having a hard time seeing what would break.
TabAtkins: Given that no one honors inline, the breaking example
is where you have 100 px wide, 80 px content and 20px
padding on both sides. You don't get a scrollbar today,
but you will.
dbaron: I'm worried about like you have random 100px scrollbars.
tantek: Webdev have worked hard to avoid random scrollbars.
TabAtkins: proposal: I would like to spec in the block axis
padding is honored on both sides. Inline is not, but
I'll put in an issue saying we'd like to make it
consistent and input would be helpful.
dbaron: Fine with me
Florian: Okay with me, but having heard you example I think it
would commonly break.
TabAtkins: That's fine. That's why I said not honored and an issue
saying let's try so someone can show how horrible it
would be.
TabAtkins: Does anyone object to that proposal?
<Rossen> http://jsbin.com/qececaqilo/edit?html,css,output
<myles> Rossen good example, that's helpful
<gsnedders> avoiding scrollbars is frequently somewhere with
browser sniffing, FWIW
fantasai: So you must put block padding because Chrome does it.
TabAtkins: It means all mobile and a good chunk of desktop is fine
with it.
fantasai: For inline we spec that you don't include the padding,
but you may and we're trying to figure it out so please
give us feedback. So a browser could ship with it.
Rossen: I don't know if you've looked at the example I just pasted.
What would be the expected behavior on that.
[everyone looks]
<tantek> Rossen, I'm seeing scrollbars in your example in both FF
and Safari
<tantek> I'm seeing interop between FF and Safari on Mac
Rossen: This is what I was trying to explain. When you have
content that outlines your padding box and content
overflowing out of that.
fantasai: The orange box is inside there and the padding box...okay
fantasai: I think in that case my expectation is the padding of
the scroller is effectively containing the geometry of
the orange box.
fantasai: What's overflowing is something we're unioning. If
you're overflowing the box it's different than the
padding.
Florian: I'm super confused.
Florian: Chrome is different than I expect.
TabAtkins: The case Rossen posted would be no change, right?
fantasai: Yes.
TabAtkins: No geometry outside the orange box.
myles: Rossen's case is different between browsers.
fantasai: The bounds of the scrollable area would no change.
TabAtkins: Outlines are crazy. Don't worry about those.
Rossen: For this purpose you're not expecting to be adding more
padding to this overflowing content from the inside box.
TabAtkins: Yes.
fantasai: They're not equivalent, but we don't expect change.
<tantek> looks like we need more offline sharing of examples /
assertions of interop
<fantasai> tantek, we're at the end of the agenda. You can hang up
if you want :)
<tantek> fantasai, I don't expect it to get resolve on the telcon
so hence suggesting a way for better understanding to
continue
<Florian> http://jsbin.com/digadoyohi/1/edit?html,css,output
Florian: I just posted a new example. In the inline FF doesn't add
padding back but Chrome does.
[everyone looks again]
Florian: The exact measure might depend on fonts.
TabAtkins: I was testing this case.
TabAtkins: I suspect I know.
Florian: I don't.
<myles> Florian's observation matches my own memory for how webkit
behaves
Rossen: Both FF and Edge have same behavior.
Florian: Safari is with Chrome.
Florian: Is Chrome doing the simple thing or is there a subtle
corner case?
<bradk> iPhone has padding to right of content.
dbaron: FWIW I *think* there was a change in Gecko 5-7 years ago
where we intentionally moved to match the spec.
dbaron: The spec being 2.1.
<fantasai> https://www.w3.org/TR/CSS21/visufx.html#overflow-clipping
<fantasai> don't see anywhere that this is addressed...
Rossen: Let's continue working on this. Based on the last 15
minutes we've already shown a bunch of different behavior.
<tantek> thank you Rossen
Florian: Which means we might be able to change.
Rossen: Let's continue working on this.
Rossen: On the ML at the least...sorry, github
Rossen: Add opinions to the issue
<tantek> highly doubtful we can change
dbaron: This might be one of those areas where it's hard to
converge on a behavior because there's UA sniffing.
Rossen: True, but in simple test cases we should have interop.
dbaron: I'd hope we can, but it's possible we might not because
this is older.
<tantek> what dbaron said
<gsnedders> I'd agree with dbaron if I had a mic
Rossen: Fair enough.
TabAtkins: Yeah
fantasai: We should try
Florian: Yeah, we should put an issue in the spec.
Rossen: I'd agree we need to work on this. There's a bunch of
things in overflow that are non-interop. Desktop web
relies on one, mobile on another.
Rossen: It's difficult to satisfy both.
Rossen: For us this would be tricky because we have all the
enterprise relying on all behavior.
<TabAtkins> This is what I tested:
http://jsbin.com/vexahocayi/1/edit?html,css,output
<TabAtkins> padding box overflows in both axises, but scrollbar only
shows up in block axis
TabAtkins: At the least, I'll put an issue in the spec
Rossen: Definitely!
Rossen: This is worth pursuing.
Rossen: It's a basic concept on how everything works
<tantek> whatever comes out of testing, I'd be biased toward fewer
scrollbars, and fewer "extra whitespace" scrolling (in
mobile / touch etc.)
<tantek> based on the fact that web devs try very hard to avoid
annoying scrollbars showing up, right at the limits of
what can be made to fit on a page
Publication
-----------
Florian: Quick question...once the issue is in the spec can we do
a WD?
Rossen: Agreed. Can we have a new WD?
<tantek> yes, new WD please
TabAtkins: Yes. We e-mailed the current editor saying we simplified.
Rossen: If there's no other things lets publish.
<fantasai> https://drafts.csswg.org/css-overflow-3/
Florian: In the private conversation we wanted to remove
max-lines, the section on we don't know how to do
overflow on print and media, the issue saying overflow-
style used to exist
<tantek> we don't have to worry about removing things before
another WD. can always remove stuff later
<tantek> just ship it
<tantek> just publish, cut later
fantasai: Let's just publish.
RESOLVED: Publish a new WD for overflow
<jensimmons> \o/
<tantek> +1
<fantasai> yay WD!
Rossen: Thanks everyone. We'll talk next week.
Received on Wednesday, 25 May 2016 23:41:41 UTC