IRC log of css on 2018-04-10

Timestamps are in UTC.

00:44:05 [dauwhe]
dauwhe has joined #css
05:48:27 [fergal_daly]
fergal_daly has joined #css
05:51:45 [kochi]
Is it too late to put constructable stylesheets in the agenda ?
05:52:49 [kochi]
(constructable stylesheets : )
05:57:22 [astearns]
I've added it to the "If there's time" section, kochi
06:00:24 [kochi]
06:42:58 [dauwhe]
dauwhe has joined #css
07:09:26 [RRSAgent]
RRSAgent has joined #css
07:09:26 [RRSAgent]
logging to
07:09:28 [trackbot]
RRSAgent, make logs public
07:09:28 [Zakim]
Zakim has joined #css
07:09:30 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
07:09:30 [trackbot]
Date: 10 April 2018
07:10:21 [astearns]
astearns has changed the topic to: FTF Schedule (will change):
07:11:45 [jihye]
present+ jihye
07:13:15 [surma]
07:15:00 [antonp]
antonp has joined #css
07:18:27 [cbiesinger]
07:18:44 [koji]
07:18:44 [birtles]
07:18:52 [dael]
present+ dael
07:18:58 [dael]
ScribeNick: dael
07:19:30 [astearns]
07:20:08 [ericwilligers]
ericwilligers has joined #css
07:20:08 [rego]
07:20:16 [smfr]
smfr has joined #css
07:20:22 [ericwilligers]
07:20:22 [Rossen]
Rossen Atanassov, Microsoft
07:20:30 [rego]
Manuel Rego, Igalia
07:20:30 [tantek]
tantek has joined #css
07:20:35 [Loirooriol]
Oriol Brufau, observer
07:20:36 [shane]
Shane Stephens, Google
07:20:42 [surma]
Surma, Google
07:20:42 [TabAtkins]
Tab Atkins, Google
07:20:47 [flackr]
Rob Flack, Google
07:20:50 [ericwilligers]
Eric Willigers, Google
07:20:52 [nainar]
present+ Naina Raisinghani, Google
07:20:57 [birtles]
Brian Birtles, Mozilla
07:20:58 [tantek]
present+ tantek
07:21:00 [dbaron]
L. David Baron, Mozilla
07:21:02 [gsnedders]
Geoffrey Sneddon, Invited Expert
07:21:04 [majidvp]
Majid Valipour, Google
07:21:05 [rune_]
Rune Lillesveen, Google
07:21:06 [jihye]
JIhye Hong, LGE
07:21:11 [iank_]
Ian Kilpatrick, Google
07:21:11 [cbiesinger]
Christian Biesinger, Google, observer
07:21:14 [astearns]
Alan Stearns, Adobe
07:21:16 [myles]
Myles C. Maxfield, Apple
07:21:18 [smfr]
Simon Fraser, Apple
07:21:23 [fantasai]
fantasai, Invited Expert
07:21:28 [rachelandrew]
Rachel Andrew, Invited Expert
07:21:29 [Guest47]
Richard Rutter, Clearleft
07:21:30 [florian]
Florian, Invited Expert
07:21:34 [tantek]
Tantek Çelik (, Mozilla, (also AB)
07:21:47 [monica]
monica has joined #css
07:22:12 [monica]
Monica Dinculescu, Google
07:22:33 [Vlad]
Vlad has joined #css
07:22:40 [Vlad]
07:22:42 [dael]
Topic: 2018 Snapshot
07:22:59 [dael]
Topic: List of features for shipping
07:23:01 [dael]
07:23:12 [plinss]
: present+ Peter Linss, Invited Expert
07:24:05 [Guest47]
Guest47 has left #css
07:24:08 [Guest47]
Guest47 has joined #css
07:24:45 [dael]
florian: The snapshot has a section with the general policy of the WG. WE don't do vendor prefixes but do draft maturity. The WG can make exceptions based on market pressure. WE don't list what the exceptions are. fantasai created proposed text and a list of examples.
07:25:29 [dael]
dbaron: One of my concerns about the list is over the past 15 years we've cleared various features at various times that are scattered across minutes. The mor complete the list is the more serious it is to have them listed.
07:25:48 [dael]
fantasai: We should get to the point where the list is comprehensive. If there are things not on the list we should add them.
07:25:54 [dael]
florian: It's a not so repub isn't hard.
07:26:02 [astearns]
section under discussion:
07:26:06 [dael]
dbaron: WE may find two or three missing over the course of a month.
07:26:09 [dael]
fantasai: That's okay.
07:26:13 [dael]
florian: Review the list?
07:26:31 [dael]
fantasai: I think my list was things we've already cleared. There's stuff we didn't clear buy shipped.
07:26:34 [dael]
florian: [reads list]
07:27:02 [dael]
florian: Chris suggested we add conic gradient
07:27:09 [dael]
florian: Focus-within?
07:27:17 [dael]
fantasai: I don't think explicitly cleared, but it's shipping.
07:27:33 [dael]
florian: That's the list. fantasai has an edit proposed. If everyone is happy we'll merge.
07:27:40 [dael]
dbaron: Is this the edit with similar text?
07:27:45 [dael]
fantasai: Yeah, we have to clean that up.
07:27:56 [dael]
dbaron: I'm fine with merging after the duplication is sorted out.
07:28:17 [dael]
florian: Are we okay resolving to merge this after editorial improvements?
07:28:27 [dael]
astearns: And going forward as we approve things edit this in.
07:28:39 [projector]
projector has joined #css
07:28:41 [dael]
fantasai: And if there's something that needs to be added to the list let us know.
07:28:54 [dael]
dbaron: There's things that should be on the list but I couldn't find minutes.
07:29:05 [dael]
fantasai: Just list and say "I think we cleared but I couldn't find miuntes"
07:29:09 [Rossen]
Rossen has joined #css
07:29:16 [dael]
dbaron: Some were over 10 years ago.
07:29:27 [dael]
fantasai: Put them in and we'll find them or re-resolve
07:29:35 [dael]
Rossen: Other suggestions?
07:29:40 [shans]
shans has joined #css
07:29:41 [dael]
Rossen: Objections?
07:29:55 [dael]
RESOLVED: Merge this text in after editorial changes
07:30:10 [sylvaing]
sylvaing has joined #css
07:30:23 [dael]
florian: There are 4 open issues. Link in the agenda. Do we want to publish before dealing with them?
07:30:39 [fremy]
fremy has joined #css
07:31:08 [dael]
florian: One is an issue in bikeshed, the indexes are slightly wrong, I wouldn't block on that. Document conformance should be added from 2.1, that should happen. But do we want to block on it?
07:31:11 [leaverou]
leaverou has joined #css
07:31:38 [dael]
florian: Last is sort of related, issue #1139. NOthing lists what the fields in the propdef table means. Snapshot could be that.
07:31:41 [plinss]
plinss has joined #css
07:31:44 [dael]
??: I think that's the right place.
07:31:55 [dael]
florian: It's a new snapshot because it's a new year.
07:32:07 [dael]
Rossen: Sure. It will be more beneficial to get the snapshot out.
07:32:16 [dael]
Rossen: Was issue should we block on those?
07:32:24 [dael]
florian: yes
07:32:44 [dael]
Rossen: Obj to proceed with publishing snapshot as-is including the open issues?
07:32:58 [dael]
RESOLVED: proceed with publishing snapshot as-is including the open issues
07:33:17 [dael]
Topic: 2019 f2f schedule
07:33:54 [dael]
Rossen: Both myself and astearns have been asked many times why we have so much agenda, we cna't make it through everything, should we go back to 4 meetings?
07:34:01 [dael]
TabAtkins: We have an open afternoon right now.
07:34:05 [dael]
astearns: It'll fill.
07:34:23 [dael]
astearns: Given the last month of telecon that were too long for the time.
07:34:39 [dael]
astearns: Unfortunately tpac is in September so it makes it awk to put 3 in before that.
07:34:51 [dael]
dbaron: TPAC will be about a month earlier then usual.
07:35:03 [dbaron]
s/then usual/than this year/
07:35:19 [dael]
Rossen: If we needed to get 4 next year that would make it hard unless we do one in December?
07:36:21 [dael]
Rossen: The fact is that at least since Seattle 2017 we've been running every meeting with parallel tracks as much as we can so we can absorb more agenda and have more focused areas of discussion.
07:36:36 [dael]
Rossen: Even with these efforts we're still running tight on the schedule.
07:37:01 [dael]
Rossen: Is 4 meetings in general something we should think about?
07:37:20 [dael]
Rossen: If we do go back to 4 we have to start thinking about what the first meeting of 2019 would look like.
07:37:40 [dael]
fantasai: Given the way TPAC is scheduled it's likely best to think how many months between a meeting.
07:37:54 [dael]
florian: Yes and no. 3 months after TPAC is December.
07:38:00 [dael]
fantasai: TPAC is end of OCtober?
07:38:02 [dael]
dbaron: Yes.
07:38:26 [dael]
fantasai: So we might do 3 meetings in 2019 because TPAC, but then it might be 4 the next year.
07:39:01 [dael]
fantasai: The problem with this is it's been 6 months since the last. IF we space out better it'll work better. I'm happy for 4 a year but if it's a short year one ever 3 months-ish will be a short year.
07:39:22 [dael]
Rossen: We know we have TPAC and TPAC-next. end of Oct 2018 and Spet 2019. THat's a shorter 11 month period.
07:39:33 [dael]
fantasai: If we want to space every 3 months we should do Jan next year.
07:39:52 [dael]
dbaron: I was trying to work out even spacing for 2 between TPAC and it's early Feb and late May/early June.
07:40:02 [dael]
fantasai: And 4 would be Jan/May/July
07:40:13 [dael]
astearns: Would anyone be able to host late Jan/early Feb?
07:40:18 [dael]
Rossen: That's the 2 meetings?
07:40:33 [dael]
astearns: That's even with the 4 because we can't move the first any further back due to holidays.
07:40:51 [dael]
TabAtkins: If we'll do Feburary we'd be happy to do another Sydney.
07:41:02 [dael]
fantasai: You've got no one based in Sydney.
07:41:07 [dael]
shane: I'll still help.
07:41:42 [dael]
Rossen: We have Sydney as a potential host in early Feb/late Jan. Any other ideas or offerings?
07:41:54 [dbaron]
I think even spacing would be early-mid February, and then late May / early June
07:42:12 [dael]
Rossen: Should we resolve on a end Jan/early Feb 2019 meeting? That's long enough after Leon TPAC.
07:42:26 [dael]
Rossen: We've got one offer for hosting and we'll figure out if anything else comes.
07:42:34 [dael]
fantasai: Maybe Apple can host?
07:42:44 [dael]
myles: Our new building doesn't have anywhere to do that.
07:43:09 [dael]
TabAtkins: We discussed yesterday and Mozilla Toronto might host in the summer.
07:43:17 [dael]
dbaron: It's nice in the summer.
07:44:07 [dbaron]
Strict averaging would say meeting the week of February 11, and then the week of either May 27 or June 3
07:44:13 [dael]
Rossen: Proposal: End Jan/Early Feb 2019 for the first winter meeting.
07:44:35 [dael]
Rossen: If we only want one meeting between that and TPAC it may be late Feb.
07:44:57 [dael]
Rossen: So we have a tentative Feb 2019 meeting and we'll have to work out logistics.
07:45:13 [dael]
Rossen: Objections to winter 2019 meeting, potentially in Sydney?
07:45:48 [dael]
RESOLVED: We will have a late jan or in feb 2019 meeting, possibly in Sydney
07:46:11 [dael]
Rossen: Based on Sydney we can see if we need to squeeze two more in that year or jsut one.
07:46:37 [dael]
Topic: meta-issue: when we don't act on some ambig we spec due to compat. latest example, having flex/grid % margins be based on oldest (block flow) model, rather than anything in the past 20 years (positioning, flex, grid).
07:47:13 [dael]
Rossen: I'm not sure who put the issue in.
07:47:33 [dael]
tantek: I put that in during the telecon where you said Edge will support horizontal % modal.
07:47:51 [dael]
astearns: As I recall we set ourselves up for this. We left ambig in the spec and let it fester.
07:47:59 [dael]
tantek: Worse, we created ambig in the spec.
07:48:09 [dael]
astearns: If anyone has ideas on how to avoid in the future.
07:48:25 [dael]
florian: Impl were already disagreeing when we made it ambig.
07:48:36 [dael]
TabAtkins: Agree. That's when we officially undefined it.
07:48:42 [dael]
astearns: Maybe we shouldn't do that.
07:49:39 [dael]
fantasai: This is the first time since I"ve been here where we had a disagreement where we couldn't agree what the spec should say. There are places where we make something undefined because we need to move forward, but we plan to align. Every time we've had technical discussion we've figured out what the spec should say. This is the first time WG was completely split.
07:50:14 [dael]
tantek: We had agreement at NY F2F and we resolved and changed the spec and then we undid it in Paris. So we started with agreement and then, correct me, but TabAtkins brought forward a case and saying we disagree.
07:50:25 [dael]
shane: I don't think that's what happened in BY.
07:50:34 [dael]
TabAtkins: Our impl disagreed and we said we'd check it out.
07:51:33 [tantek]
Resolution from 2015 NYC f2f
07:51:33 [florian]
florian has joined #css
07:51:37 [dael]
Rossen: Agreement on symetric resolution of % was led by us based on how we wanted overall model of grid. One of the guidance principals was we wanted it as symmertric as possible. When we discussed we generally agreed this is the right modal to have. If it was in a vacuum I don't think we would have changed.
07:51:43 [tantek]
"RESOLVED: Flexbox top/bottom margins and padding resolve against height."
07:52:35 [dael]
Rossen: However we had a requirement to keep flexbox same as grid. When we wanted to backport flexbox it was already widely implemented. People were using the % padding hack for aspect ratio and that was a problem for Google when they tried to flip to the new model. Google came back and said they'd break everything.
07:53:13 [astearns]
as much as is possible I would like to limit the re-litigation of this particular issue, and instead see if there are suggestions on how to avoid this impasse in the future
07:53:19 [dael]
Rossen: It wasn't a disagreement, it was a statement of facts that we are going to break the web. What tantek is pushing for is we have a model that makes perfect sense and we have new people using grid and flexbox and let's have something that makes sense.
07:54:05 [dael]
Rossen: Fastforward to 2 months ago, we were the only ones shipping grid for a long time. When other impl shipped grid we had more and more pressure to fix the bugs.
07:54:27 [dael]
Rossen: I think this is more of an outlier then a practice we have. I don't think we've had this drastic reality. Yes we must avoid this on all counts.
07:54:47 [dael]
florian: I don't see how we find a process to avoid getting stuck on not agreeing. Once you have the split, what do you do?
07:55:50 [dael]
tantek: Other reason given to have the split is the potential utility of the aspect ratio hack, if that's something we want we should have a feature for that. We as a group didn't follow through and that's also partly to blame. If we were to have a good proposal that might have been a way out of the compat mess. That didn't happen.
07:56:17 [dael]
tantek: I understand we've been backlogged on agenda and bottlenecked on editors, but with hindsight that might have been avoidable.
07:56:48 [dael]
fantasai: There was also a fair number of comments in the bug where author feedback was also split. A bunch of authors wanted it to work the way MS did and a bunch that wanted Chrome.
07:57:55 [dael]
fantasai: Some were about aspect ratio, but some where about other aspects of using it. If there had been strong feedback one way or the other that would have pushed us a way to go. We had a split in the WG and a split in feedback. I don't think that's a pattern we tend to follow. Yes, we were backlogged and in hindsight. But I don't think this is a systematic problem.
07:58:23 [fantasai]
s/in hindsignt/in hindsight there are always things we could have done better/
07:58:25 [dael]
astearns: We can close this saying we don't think this is a good pattern and we don't think we normally do it, but if anyone sees us falling into it please call it out.
07:58:51 [dael]
tantek: Because we had split author feedback combined with that the browsers hack were pressured.
07:59:06 [dael]
astearns: When we find outselves in a place where we want ot leave something undefined we need to do analysis
07:59:16 [dael]
tantek: WE did analysis. We knew we needed the feature.
07:59:23 [dael]
fantasai: People disagreed on right thing.
07:59:36 [dael]
florian: It was not the only issue. If aspect raio had been solved it may have helped.
07:59:43 [fantasai]
s/right/what was the right/
07:59:54 [dael]
tantek: To solve it we needed and aspect ratio solution. It might not have been enough.
08:00:10 [dael]
tantek: If we're ever tempted t oundefine we should use this as a prediction of what will happen.
08:00:24 [dael]
fantasai: WE knew this would happen. We'll put both and someone will have to switch.
08:00:43 [dael]
florian: There was a note from the time saying it was sucky.
08:00:44 [fantasai]
s/switch/switch due to web compat/
08:00:58 [dael]
tantek: You don't have 2 major impl sticking with one way of doing it for no good reason
08:01:57 [dael]
fantasai: We knew it would come to a web compat fist fight. WE could not come to a consensus. WE discussed many times for hours. You can't tell us we didn't try. We decided this will suck, we have two impl, and web compat will drive it in one direction or another. WE've never had that problem before and I don't expect us to have it again.
08:02:21 [dael]
fantasai: We'll always have web compat. They're not due to intention of the working group. THat's what happened here and makes it different from every other case.
08:02:31 [fantasai]
s/compat/compat bugs/
08:02:42 [fantasai]
s/what happened/not what happened/
08:03:24 [dael]
Rossen: I think the lessons have been learned. I don't think we can have anything in a more formal way to avoid these sort of issues. I don't believe we've made such issues intentionally besides this one. I'd encourage anyone who wants to come up with a process to put your thoughts on the wiki to say this is a dangerous one and let's not repeat the padding/margin issue.
08:03:43 [dael]
Rossen: It sucks when this happens, users the most, because they get crappy output, but that's where we ended.
08:04:13 [dael]
tantek: There's an additional conclusion which is when there is web author demand for a feature and that's expressed via a hack that should be a strong signal to the group to make it official.
08:04:31 [dael]
TabAtkins: tantek that's a spec you could have edited.
08:04:42 [dael]
fantasai: You're complaining why didn't anyone submit a patch.
08:05:10 [dael]
tantek: Any of us could have done it. I'm making a forward looking statement where if we see this in the future it behooves us to pay attention.
08:05:25 [dael]
Rossen: We can make a new flag in github saying to elevate this.
08:05:29 [dael]
florian: You can't with a missing feature.
08:05:33 [dael]
Rossen: Why not?
08:06:14 [dael]
tantek: Prior example was advancemenet with animations and transitions back in 2000s with webkit. It was massive changes to the platform where we didn't act soon enough and we had to endure a lot of pain.
08:06:29 [dael]
Rossen: Let's move on.
08:06:41 [dael]
Topic: Editorship of css-page-floats
08:07:23 [dael]
florian: johannas is the only editor of page floats and he's not funded to do this work. He's uncomfortabe both that it's not progressing and that his name on it and it's not progressing.
08:07:42 [dael]
florian: I think it's good to have multiple people on the hook. rachelandrew raised her hand and I'm interested.
08:07:57 [dael]
rachelandrew: I'm happy to take it on, it has relation to the work I'm doing in multicol
08:08:18 [dael]
florian: I would propose to add rachelandrew and I in addition to Johannes
08:08:26 [dael]
Rossen: Is Johannes inerested in remaining?
08:08:27 [dael]
florian: Yes.
08:08:39 [dael]
Rossen: Objections to adding rachelandrew and florian as editors to page floats
08:08:47 [dael]
RESOLVED: add rachelandrew and florian as editors to page floats
08:08:57 [dael]
Topic: definition of box-sizing in css-sizing
08:09:04 [dael]
08:09:14 [dael]
florian: Had resolution to move the definition to css sizing
08:09:33 [dael]
florian: There was a large re-write while it happened. I filed this to disagree with some of it.
08:10:17 [dael]
fantasai: We want to add a normative reference to UI 3. 2.1 refers to width and height but doesn't say if it's inner. UI 3 has a diff written in English to figure out how it works. It's an awful bit of spec writing we shouldn't add.
08:10:41 [dael]
fantasai: Proposal is add a normative reference from CSS Sizing to UI 3. Also maybe fold the edits into 2.1 so it's not necessary to have this.
08:11:09 [dael]
florian: And this monkey patch once written is mostly obvious, but when unwritten it's not clear.
08:11:22 [dael]
florian: For referring to the monkey patch sounds good.
08:11:43 [dael]
florian: Other part I raised is that you defined normatively width to mean inner-width and we haven't checked all our specs.
08:11:54 [dael]
fantasai: In 2.1 any instance where it's ambig it's the inner width
08:11:56 [tantek]
tantek: and test cases revealed bugs in the definition as well that we had to fix in css-3-ui
08:12:01 [dael]
florian: Sometimes it means the value of the property.
08:12:47 [dael]
fantasai: In those cases it's the value minus borders and padding. THat enture monkey patch it's the inner width. The fundimental concept of 2.1 is it's inner width. There might be cases outside of CSS 2 where we were less careful, but those are bugs in the spec.
08:13:40 [dael]
florian: What I was thinking about is in practce in practical speech they're unavoidable. I'd rather normatively define and anchor term that's non-ambig so if you run into width you don't have to wonder if they meant innor or forgot to be careful
08:14:16 [dael]
tantek: Aslo dimensial width vs [missed] It's not just inner vs outer, but also the width as a property in cascade. There's multi levels of ambig going on.
08:14:34 [dael]
florian: To solve that I'd like the inner to be an anchor term which you can link the in bikeshed.
08:14:43 [dael]
dbaron: Are the places where we say width and mean inline size?
08:15:00 [dael]
florian: That too. In enough cases it's ambig but obvious enough and in those cases we should fix.
08:15:00 [tantek]
s/Aslo dimensial/Also dimensional
08:15:15 [tantek]
s/vs [missed]/vs property width, computed, cascaded etc.
08:15:24 [dael]
dbaron: I think the fact that there is a second thing we ought to audit for maybe we should not assume here.
08:15:42 [dael]
fantasai: CSS L3 I haven't looke dat position, but the rest are careful to use block size.
08:15:46 [dael]
dbaron: But non-layout.
08:16:05 [dael]
fantasai: Any spec TabAtkins or I worked on is being careful. Anyone else editing might want to look.
08:16:32 [dael]
tantek: I think we're not focusing on the issue. I think we should resolve this that CSS UI defines box sizing. And then the plan moving forward is separate.
08:17:17 [dael]
fantasai: Box sizing moved tot he sizing module. florian opened asking for the monkey path to be copied into box sizing. I think it's better to nromaive reference CSS UI from Sizing. Box sizing should have been in the sizing spec so it was in CSS UI.
08:17:25 [dael]
gsnedders: CSS UI 3 have a normative reference?
08:17:51 [dael]
tantek: No. It's fine in CSS3 UI and it's because form element behave that way. For external specs I'm not sure why we're talking double direction here.
08:18:25 [tantek]
s/form element/form elements
08:18:35 [dael]
florian: Prop is keep the box sizing definition out of UI 4 and into Sizing with a reference to the monkey patch in sizing and refer to sizing where it has better sizing. Mostly defined in sizing and refer to the monkey patch to CSS UI 3
08:19:00 [dael]
florian: To be able to apply the monkey patch to 2.1...the other thing you dropped from UI to sizing is that i normatively defined width and the like.
08:19:36 [dael]
fantasai: Box sizing has the terms defined but in pieces. Inner is separate from min/max size. But the terms to exist in sizing. I didn't feel like duplicating your version.
08:19:42 [dael]
florian: I felt you underfined them.
08:20:40 [dael]
fantasai: Inner is defined in sizing. In CSS 2.1 the spec is written witht he understanding that width means inner-width. If you want to read it with the context of width existing you need to know that. MOnkey patch can be compressed to a sentence saying it's referring to ineer-width/height. All your changes were about that.
08:21:03 [dael]
fantasai: I think we should resolve on having 2.1 so that the potentially ambig references to width are corrected so we don't need awk patch.
08:21:15 [dael]
tantek: We need to open an issue. This issue is multi spec.
08:21:21 [dael]
fantasai: That's fine.
08:21:21 [gsnedders]
I am strongly in favour of fixing 2.1 here.
08:21:26 [dael]
Rossen: Let's take resolution to 2.1
08:21:30 [tantek]
s/open an issue/open an issue on 21
08:21:34 [tantek]
08:21:35 [dael]
florian: Can we normatively reference the monkey patch from sizing?
08:21:36 [dael]
fantasai: Yes
08:21:49 [fantasai]
s/width existing/box-sizing existing/
08:22:21 [dael]
Rossen: We need to update CSS 2.1 by normatively pointing UI 3?
08:22:26 [dael]
fantasai: 2.1 to be edited.
08:22:38 [dael]
tantek: That's why I'm suggesting a separate new issue.
08:22:42 [dael]
Rossen: What's the 2.1 fix?
08:23:03 [fantasai]
08:23:03 [dael]
tantek: In florian's long comment on 2458. Errata CSS 2.1 bullet point.
08:23:33 [dael]
florian: Trying to craft the wording isn't group. We should open the issue and until we fix 2.1
08:24:01 [dael]
Rossen: Prop: Add an issue and a fix for 2.1 to disambiguate width for inner and outer width.
08:24:04 [dael]
Rossen: Obj?
08:24:12 [dael]
RESOLVED: Add an issue and a fix for 2.1 to disambiguate width for inner and outer width.
08:24:18 [dael]
Topic: end
08:24:40 [dael]
<br type="15min">
08:25:55 [Ms2ger]
Ms2ger has joined #css
08:27:55 [smfr]
smfr has joined #css
08:50:25 [gsnedders]
FYI: I want to have some discussion about future editing of 2.1 at some point during the week, probably as some breakout at some point.
08:51:29 [tantek]
gsnedders: count me in :)
08:51:34 [dael]
Rossen: Let's get going
08:51:41 [dael]
Topic: Move overscroll-behavior spec from WICG to csswg-drafts
08:52:00 [dael]
Rossen: WE need to action someone to do the updates of 2.1
08:52:03 [dael]
Topic: 2.1
08:52:23 [dael]
Rossen: We still have one 2.1 editor in the room. So we can action him to make the errata edits.
08:52:34 [dael]
florian: I think we should be setting up the build system.
08:52:41 [dael]
fantasai: gsnedders should be working on it
08:52:52 [dael]
Action tantek to make updates to CSS 2.1 Errata
08:52:58 [trackbot]
Created ACTION-871 - Make updates to css 2.1 errata [on Tantek Çelik - due 2018-04-17].
08:53:25 [dael]
[planning for dinner]
08:54:17 [dael]
Topic: Move overscroll-behavior spec from WICG to csswg-drafts
08:54:24 [dael]
08:54:31 [tantek]
In practice we have 3 2.1 editors in the room, since fantasai has been editing 2.1 for many years in practice, and gsnedders voluntered to edit 2.1 also
08:54:46 [gsnedders]
And we have a resolution adding me as an editor from last year.
08:55:00 [tantek]
(those two statements should be outside of this issue)
08:55:04 [dael]
astearns: We resolved to do that. And we're still waiting on Facebook to join. majidvp added a comment saying it'll be okay, please do this thing. Hopefully they'll find time to continue the spec.
08:55:11 [dael]
astearns: You're not interested in co-editing majidvp ?
08:55:28 [dael]
majidvp: I mentioned in the discussion I'm happy to be the fallback, but I prefer the original editor.
08:55:42 [dael]
astearns: Hopefully soon we can get Facebook in and you two can continue.
08:55:45 [dael]
Rossen: majidvp thank you.
08:55:56 [dael]
Rossen: Do we have a timeline on when this will come from WICG?
08:56:02 [dael]
astearns: TBD because we need an editor.
08:56:11 [dael]
Rossen: If we added majidvp today can we move the spec?
08:56:18 [dael]
astearns: It's overcommitting majidvp I think.
08:56:29 [dael]
majidvp: The right thing is give the current editor some more time.
08:56:34 [dael]
astearns: We'll wait on a response.
08:56:45 [dael]
Topic: Writing modes update
08:58:01 [dael]
fantasai: Status is that there are some tests failing. Main issue...some we can explain as impl bugs. Main issue is that the automatic sizing of orthogonal flows, we didn't have interop to begin and then we added rules for scroll containers. There's no impl of what's in the spec. It's not a difficult fix.
08:58:17 [dael]
fantasai: Status is we should have an impl report soon to show, but we need a couple of bug fixes.
08:58:34 [dael]
fantasai: I was going to finish impl report, but got sick so it hasn't happened yet.
08:58:42 [dael]
Rossen: Is impl something you need help?
08:59:04 [dael]
fantasai: I just need a day. koji and I spent time going over test results. It's just taking them and putting them in a document that explains.
08:59:25 [dael]
fantasai: We need bug fixes and updated CR> We should also CR in writing modes L4. It's everything we cut from L3.
08:59:30 [dael]
astearns: Is there FPWD?
08:59:32 [dael]
fantasai: Yes.
08:59:40 [dael]
florian: Sideways, sideways-lr
08:59:50 [dael]
dbaron: All maintenence?
08:59:55 [dael]
fantasai: Duplicated
09:00:16 [dbaron]
s/maintenance/maintenance to level 3 also in level 4/
09:00:17 [dael]
fantasai: Updated CR for L3 and transition to CR for L4 and we'll need 2 impl of the sizing stuff in the spec.
09:00:59 [dael]
koji: We also need to make an exception for the PR. fantasai can do the change in 2 weeks for Gecko. I don't have a timeline for Blink so may not get second Impl in time. I don't think it's worth to wait.
09:01:30 [dael]
florian: WE need to convince W3M that we should ignore these things. Fix is easier the explain away if it's reasonably easy
09:01:50 [dael]
koji: Our impl...I'm doing other positioning.
09:01:51 [astearns]
s/the explain/than explain/
09:01:55 [Rossen]
s/Is impl something you need help/Is impl report something you need help/
09:02:01 [dael]
dbaron: Is there stuff going to CR in L4 that hasn't been to CR before?
09:02:19 [dael]
fantasai: Nope, it's just a straight copy of what's been there before.
09:02:32 [dael]
Rossen: Let's get a resolution to republish Writing Modes L4
09:02:40 [dael]
fantasai: L4 transition to CR, L# update CR
09:02:47 [dael]
Rossen: Obj to transition L4 to CR
09:02:57 [dael]
RESOLVED: Transition L4 of writing mode to CR
09:03:09 [dael]
RESOLVED: Republish L3 writing modes CR
09:03:24 [dael]
florian: Do we have to set a minimum time before it can PR?
09:03:28 [dael]
Rossen: 4 weeks is okay.
09:03:39 [dael]
RESOLVED: CR transition period for L3 is 4 weeks
09:03:58 [dael]
Rossen: Anything else on writing modes?
09:04:01 [dael]
fantasai: Not at this point
09:04:11 [dael]
Topic: Spatial navigation
09:04:29 [dael]
Topic: Status Update on work in WICG & Demo
09:04:46 [dael]
Demo link:
09:04:58 [dael]
Spec Link:
09:05:37 [dael]
jihye: spacial navigation is ability to nav between focusable elements.
09:06:29 [dael]
jihye: florian and I introduced this last year. Most browsers have not histocially offered these features. Some browsers have allowed it using arrow keys. No browser now provides it by default. Some web apps provide using JS libraries.
09:06:47 [dael]
jihye: We thought to spec basic behavior and provide some overriding APIs of the default behavior.
09:07:03 [dael]
jihye: [shows spec]
09:07:33 [dael]
jihye: florian and I wrote the ED. It includes processing model which is basic browser behavior. We're writing overriding APIs and the CSS property.
09:07:54 [dael]
jihye: I also made a polyfill based on the spec. It's not complete, but supports main behavior
09:08:38 [dael]
florian: This is mostly not a CSS spec right now. From a CSS sense it's as if everything was auto. We need to say what happens when a user tries to do things when everything is auto and then we have some JS for chaning auto.
09:09:29 [dael]
florian: We started with CSS properties but with limited data on what authors and users want we thought it was better to get the basic APIs and then add additional CSS properties based on what people do with JS. This works without JS, but the JS overrides. The questions we have later is things the depend on layouts.
09:09:30 [dael]
jihye: [shows demo]
09:10:13 [dael]
jihye: In the page there are several focusable elements and you can nav using arrow keys. You can do with tab, but you have to press more times. Web apps using inline layout spacial nav is very useful.
09:10:33 [dael]
jihye: [shows a page with many examples of layout]
09:10:54 [dael]
jihye: There's many corner cases, including hover cases.
09:11:54 [dael]
florian: One of this thing we're interested in seeing is the long standing questions about re-ordered sequential navigation and we think they want spacial navigation. We're interested to see if people still want the re-ordered sequential after we've done this.
09:12:14 [dael]
tantek: There's always been an a11y desire to make sequential work without a spacial view.
09:12:20 [dael]
florian: This is a side note.
09:13:51 [dael]
Rossen: We've been impl and shipping spacial nav on Xbox with Edge for a few releases. WE've precieved it as a general UI nav and for that reason we're allowing a generic UI for a11y and anything, including XBox controller or input based on connect motion or verbal commands is just working. WE don't have to deal with all modes of input and user input, that's tempered by a11y interface.
09:14:55 [dael]
Rossen: Also, from what tantek said, I've been in the APA WG and that's been their top gripe aboutflexbox and grid and everything else. I'm very interested in anything we'll do to help those efforts. If we're not solving this for a11y as well I think we're missing out.
09:15:02 [tantek]
agreed with Rossen
09:15:52 [dael]
florian: We have an open issue saying if you have use cases not solved by spacial nav for reordered sequential please tell us. We haven't heard, but maybe don't have the right eyes. I don't think there's anything incompat, but I've heard conflicting requests for the seqential and some of them may be solved.
09:16:04 [dael]
tantek: It's better to look through minutes for a11y meeting
09:16:22 [dael]
florian: There's multiple people saying conflicting things.
09:16:29 [fantasai]
s/There/I did. There/
09:16:31 [dael]
florian: But that's not what we wanted to talk about today.
09:16:48 [tantek]
s/a11y meeting/joint CSS WG and a11y meeting at TPAC 2017
09:18:08 [dael]
florian: For issues, one thing that became apperent is stat nav isn't easy. If the first focused button is several pages down you want to scroll until you get to it. When we tried to spec in relation to scroll we found it difficult to define in terms of CSS. There's some in overflow, some in scroll snap points, some in CSSOM view which defines API. These bits are not well integrated. The more proceedural approach in CSSOM view doesn't talk about snap points.
09:18:16 [jihye]
09:18:20 [fantasai]
s/conflicting things/conflicting things. I suspect that some of these conflicts would go away once we have spatnav/
09:18:20 [dael]
florian: We have two issue son the agenda. #2322 and #2323
09:18:21 [jihye]
09:18:41 [myles]
09:18:41 [dael]
florian: IT's the desire for a scrolling spec to exist. #2322 we found a need to refer to a thing that can be scrolled.
09:18:49 [myles]
09:18:50 [dael]
09:19:01 [dael]
fantasai: Do you want something that can be scrolled by the user
09:19:04 [Rossen]
09:19:52 [dael]
florian: Yes and that can be manually scrolled. It's not already scrolled all the way in. If it's all the way down it cannot. If it's the last mandatory scroll point you cannot. If a use wants to scroll in this direction, could they? We found a need to try and talk to that. You can describe this, but there's no single term.
09:20:00 [dael]
fantasai: What do you want the WG to do?
09:20:38 [dael]
florian: These two issues call for a scrolling spec that folds all the things in so that we don't have to talk about proerties from many specs when talking about scrolling. What's the WG stategy to make scrolling easy to refer to.
09:21:05 [dael]
fantasai: Termonology in Overfow makes sense if it's general. If it's API-based it should be in there.
09:21:12 [dael]
florian: This is anchoring termonology.
09:21:16 [dael]
fantasai: CSS Overflow
09:21:47 [dael]
florian: We needed a thing that can be manually scrolled in another direction and the other is scroll directionally by a UA defined amount taking into account all the other properties.
09:21:55 [dael]
fremy: Scroll a single user?
09:22:04 [dael]
florian: If you pressed the down arrow, find an anchoring term
09:22:11 [dael]
fantasai: Scroll in intended direction.
09:22:12 [fantasai]
09:22:22 [dael]
florian: There's the classification of things in Scroll Snap.
09:22:38 [dael]
fantasai: We can move that section to Overflow.
09:23:24 [dael]
Rossen: I think what fantasai said is CSS Overflow is where termonology should be. If it's not there point it out. In terms of additional features that live on those termonologies, we shouldn't have base definitions in snap points
09:23:41 [dael]
florian: So propose terms to Overflow with notes to spec how they effect that term
09:24:10 [dael]
majidvp: Overscroll introduces scroll boundary and that's something you alluded that you needed so it makes sense to refactor.
09:24:17 [dael]
florian: I'll propose the relevent edits.
09:24:37 [dael]
Rossen: For issue #2322 do you need anything for the group?
09:24:53 [dael]
florian: No, I need to propose.
09:24:58 [Rossen]
09:25:02 [Rossen]
ack myles
09:25:27 [dael]
myles: I wanted to ask for clarifcation on the xbox. Were you talking about logicial vs visual ordering or talking about making the API work for a11y
09:26:44 [dael]
Rossen: Mine was about that we've been asked many times to help a11y WG by defining how the flexbox reordering, or grid, plays nicely with a11y. a11y for all the providors today is still tree based and based on content order. If you reorder using flex order or you target visually different grid cells you are disconnecting visual order from content order.
09:26:58 [dael]
Rossen: This has been the #1 issue the a11y WG has been asking us to help them solve.
09:27:49 [dael]
Rossen: They have also been asking in addition for help with generla spacial nav. Put aside flexbox and grid, if they have a canvas with a bunch of little thing sin side how do the spacially navigate. Like with a map. Then going back to HTML/CSS how do you nav over a document.
09:28:33 [dael]
Rossen: I sympathize with the effort. I hoped florian and jihye work would help with both things. I hoped that they wouldn't reinevent the wheel with how it currently works. If this is something that can aid this.
09:29:14 [dael]
florian: Clarification. We're trying not to reinvent. Our model is closer to the one that exists in Chrome. It doesn't exist by default, but you can get it in a console command and it's similar to presto. I don't know the type of stat nav.
09:29:27 [dael]
iank_: It's similar to presto when it was in opera.
09:29:34 [dael]
Rossen: myles does that answer?
09:29:36 [dael]
myles: Yes.
09:29:41 [Rossen]
09:30:12 [dael]
Topic: Missing box termonology
09:30:21 [jihye]
09:30:21 [dael]
09:31:25 [dael]
florian: background 3 says border radius changes border edge. If you link to border edge it doesn't say if it effects it. The spec that does talks about border edge but not the other varius boxes. It makes it really awk to refer to in other specs. If we can define the border edge in level 3
09:31:34 [dael]
TabAtkins: I like shaped border edge to refer to it.
09:31:43 [dael]
florian: And we can add all the thigns that can be shaped.
09:31:50 [dael]
TabAtkins: WE wanted to refer to the things outside.
09:31:56 [dael]
florian: If it effects hit testing it should be there.
09:32:13 [dael]
iank_: clip-path yes, but I don't believe share-outside
09:32:24 [dael]
florian: Editors will do it? I think it's border and backgrounds L3
09:32:28 [dael]
TabAtkins: Sure. Seems fine.
09:32:52 [dael]
astearns: Since it's just missing testing to go to's just a term. As long as you don't open hit testing in backgrounds and border I'll be happy.
09:33:07 [dael]
Rossen: prop: Add the definition of the border shape edge to Borders and Backgrounds L3
09:33:13 [dael]
RESOLVED: Add the definition of the border shape edge to Borders and Backgrounds L3
09:33:33 [dael]
Topic: hitability testing
09:33:40 [dael]
09:33:54 [dael]
florian: Is this an operation that we can use or is it hard to impl?
09:35:11 [dael]
florian: When you have dialogs or things popping over a page you can't click on the things behind. Currently tab nav can get behind, but spat nav is relatively new. It would be nice that if an item can't be clicks on it can't be navigated to. It could be possible to declare these things as inert, but if we didn't have to ask authors it would be good. Can we or is it hard to impl?
09:35:21 [dael]
tantek: It would require nomative reference to can you click on it.
09:35:34 [dael]
florian: We haven't defined how hit testing works so we don't have to depend on it.
09:35:45 [dael]
iank_: If there's a 1px edge and you want to test exposed.
09:35:57 [dael]
florian: If it's barely visible then you made it visible.
09:36:13 [dael]
iank_: This is asking for hit testing on an area and you have to determine the area.
09:36:27 [dael]
smfr: As you scroll and animations run you have to animate every frame. IT's super hard.
09:37:17 [dael]
Rossen: Every imple layers differently. WE layer for perf. We layer things interdendently for painting and hit testing doesn't benefit on that. Mech of doing hit testing may suffer, but hit testing isn't highly demanding.
09:37:57 [dael]
Rossen: Thing to point out, though, I would encourage you to take a look at HTML AAM or ARIA AAM and see how they go about it. They define landmarks and all of the sites I've seen with pop ups they have a11y.
09:38:36 [dael]
florian: There are mech to say obscure things aren't interactive. Given our thing doesn't have compat bagagge if it's necessary for authors to make them do it that's okay, but if it could be authors don't have to do anything it's a nicer experience.
09:38:48 [dael]
Rossen: You'd discourage authors to do what's rec for a11y reasons.
09:39:03 [dael]
florian: I'm hearing hard to impl and poss not desirable, don't do this.
09:40:04 [dael]
fremy: We have a JS exposed function called ms-elements-from-rect where we return all elements that match the rectangle. Rectanlges are easy but chapes and SVG things get harder. If you want to define this as there is an element for the entirey of the object. Can you click on some pixel is hard.
09:40:14 [dael]
Rossen: And then you get into the argument of where is the origin of the pixel.
09:40:32 [dael]
fremy: If you want to see if there is one object that completely covers and object that's easier.
09:40:43 [dael]
Rossen: And with this you don't get the order of the rects.
09:40:53 [dael]
florian: So rely on author actively disabling things.
09:41:14 [dael]
Rossen: Which they should do for a11y. I would continue encouraging people to support that a11y agenda. It should work for everyone.
09:42:01 [dael]
tantek: florian you said you saw contradicting items. most comprehensive write up is James Craig. I would reach out ot him to ask for him to point you to latest thinking
09:42:03 [dael]
Topic: Interaction media feature navigation: none | sequential | spatial
09:42:14 [dael]
09:42:22 [jihye]
09:42:24 [florian]
09:42:29 [tantek]
s/write up is James/write-up is from James
09:42:55 [dael]
florian: We have a few media features that let you test input device to try and help author of page media query their way into more convenient UI
09:43:15 [dael]
florian: We propose it would be useful for an author to know if user has sequential or spacial nav available to them.
09:44:00 [dael]
florian: If you're on a think that lacks a mouse but has stat nav grid is fine. If you lack a mouse and stat nav you likely want visually linear. Having a ability to know if they match seems useful.
09:44:11 [dael]
florian: I made a PR, can we add that to MQ L5.
09:44:21 [dael]
florian: Web signage would be an example.
09:44:46 [dael]
fantasai: Reasonable to me. might want to distinguish 4 direction navigation and navigation that can go in many directions.
09:44:54 [dael]
florian: I'd suggest opening that as an issue on the feature.
09:44:57 [dael]
fantasai: Okay.
09:45:18 [dael]
smfr: I'm slightly opposed to a MQ that exposes a user setting because it's extra fingerprintting.
09:45:37 [dael]
Rossen: If you have a mobile decide and connected to a hub that gives you board and mouse, what's the expectation.
09:46:09 [dael]
florian: It's also for authors to not be unreasonable. You can add an ability to hover when there's a mouse. You could reorder the whole page at that itme, but it would not be wise.
09:46:14 [myles]
myles has joined #css
09:46:19 [fantasai]
09:46:52 [dael]
Rossen: I also want to echo smfr concern about user fingerprintting. We're going through extreme efforts to not bleed anything into the user logic level that would ID users with disabilities.
09:47:10 [tantek]
Also want to echo concerns about fingerprinting
09:47:21 [dael]
florian: I think this is different where devices that provide this always and devices that allow it. if it's an opt in functionality we can say you're allowed to opt-in.
09:47:50 [dael]
dbaron: I'm a little sceptable to the fingerprining because the site can tell what the user is using. They'll get mouse events.
09:48:11 [dael]
smfr: True if those events go to a frame doing detection. be detection without user input is more dangerous.
09:48:22 [dael]
fantasai: I would hope we'd get more browsers impl spacial nav.
09:48:33 [dael]
myles: Would MQ enable when you press modifier.
09:48:47 [dael]
florian: The MQ would not be on when you press a key, it's on when you're in a browser where you can.
09:49:29 [dael]
myles: So every page gets this MQ when you update your browser the internet looks different...being a spacial nav enabled browser is different then saying optimize your site for spacial naviagtion.
09:50:09 [dael]
florian: I don't think it means perfer. It's like when hover is on. If I'm about to do a design that would look terrible without that feature, I should rethink when you don't.
09:50:40 [dael]
florian: This isn't meant as a request for prefering design for stat nav. Design for stat nav is typically a typical design.
09:50:53 [dael]
myles: So if every major browser ships, what would a web author do with this MQ?
09:51:37 [dael]
florian: If you're on a device with no pointer but there is stat nav it's reasonable to have the same main layout we see. If their's neither it's not so great. If you're on a TV with no tab key you might want to know.
09:52:36 [dael]
smfr: Are there any UA where tab is only form of nav? WE should envourage people to write web content that works everywhere, not content right with a mouse but terrible with tab. This feels a bit too far. And we shouldn't assume there's UA with only terrible tab navigation. Those are bad UA.
09:52:41 [dael]
smfr: I'd prefer not to have this.
09:52:58 [dael]
florian: Summerize the feedback as "hmm maybe, come back with stringer use cases"
09:53:00 [dael]
smfr: Yeah.
09:53:09 [astearns]
09:53:17 [dael]
Rossen: I'd say "hmm not really but if you come back with something stronger we'll reconsider"
09:53:27 [dael]
Rossen: Anything else for spacial nav?
09:53:37 [dael]
florian: Just a request for people to look at what we've done.
09:53:39 [florian]
09:53:43 [dael]
Rossen: That's jihye and florian
09:53:58 [dael]
Topic: Complex float shapes and bfc sizing
09:54:08 [dael]
09:54:32 [dael]
fremy: [whiteboards]
09:55:01 [dael]
fremy: Issue is pretty simple
09:55:43 [dael]
fremy: When you have a float and another float later that has a different shape constraint. We try and size the BFC with the remaining space in the block. If your BFC is taller then the point where size constraint changes then you have to do something.
09:56:22 [dael]
fremy: In FF every time this happens a new layout is drawn and we try to resize the BFC. It's repeated as many times and needed. It's an arbitrary number of relayouts.
09:56:37 [dael]
fremy: Chrome looks like some weird behavior where they tried to do it but it broke websites.
09:56:49 [dael]
fremy: We'd like to find something int he middle
09:57:16 [dael]
Rossen: We'll layout in the first available space and then slide the other block down until we find space. We're optimizing for not relayout so we avoid overlap
09:57:23 [dael]
astearns: But you're not using the width of the space.
09:58:04 [dael]
Rossen: We are. The BFC might become wider and shorter so you don't intersect. When I wrote this in like IE9 you do an intersection with all yoru geometry until you fit the space in your initial BFC and you use that.
09:58:14 [dael]
iank_: Did you change recently?
09:58:18 [dael]
Rossen: Maybe but not so much
09:58:40 [dael]
fremy: We do first layout and move the box at the first place you fit.
09:58:46 [dael]
Rossen: We may not do relayout.
09:59:28 [dael]
dbaron: One problem with the description. While making something wider generally makes it shorter, sometimes it makes it taller. Like when you have an overflow:hidden and the image has a fixed width if you make it wider the image get taller.
09:59:44 [dael]
dbaron: You can't assume that it's going to not overlap.
10:00:10 [dael]
dbaron: Other thing is these overlap cases happen on real websites, esp wikipeia. Browsers that get this wrong have overlapping content in wikipedia.
10:00:29 [dael]
dbaron: FF in wikipedia cases have like 3 layouts.
10:01:02 [dael]
iank_: We looked into this. We think our current impl is a little funky. One thing we can do is you look for next available area that is unbounded and doesn't have a float blocking it off at the bottom.
10:01:36 [dael]
Rossen: You can have a zig zag of floats. If you want to start filling it with a zig zag you'd push the first BFC down in this case.
10:01:46 [dael]
iank_: It will skip the zig zag. That's the best 2 pass.
10:02:35 [dael]
fremy: 2 pass option, first we try and use the size. If you overflow with another float you can try to get the smallest distance that you have in the future and try to layout in that space. If that's more then the minimum space you do the usual.
10:02:44 [dael]
Rossen: What do you mean it'll work in 2 passes?
10:03:19 [dael]
fremy: If it doesn't work we do edge behavior, but if it does you find the smallest space in the future. You simplify the geometry and the remaining space is what you try to use.
10:03:31 [dael]
Rossen: Furthest left and furthest right can be disjointed.
10:03:43 [dael]
fremy: To get 2 passes. [missed]
10:03:51 [iank_]
Here is a testcase I created a while ago...
10:03:52 [dael]
florian: So furthest left and right, not shortest distance.
10:04:14 [dael]
dbaron: There's one assumption about gecko you made that I think is wrong. I think you assumed we did a layout...let me check...
10:04:38 [dael]
dbaron: I think we're using intrinisic min-content width and not doing layout.
10:04:49 [dael]
dbaron: We're doing a layout to determine the height.
10:05:04 [dael]
Rossen: That's the one we're talking about. THe widths are created by the geometry.
10:05:08 [dael]
dbaron: I need to read it.
10:05:31 [dael]
iank_: One thing to point out is when you introduce margin collapsing if the BFC 'smargin effects position of floats.
10:05:54 [dael]
Rossen: If BFC psoitions after the floats it will have to be in content order. Only thing that could be effected is BFC position
10:06:03 [dael]
iank_: Margins collapsing through in an empty div.
10:06:09 [dael]
Rossen: But they're already committed.
10:06:15 [dael]
iank_: Not until you know the final margins.
10:06:36 [dael]
iank_: You can have a margin that's further down in the doc that effects where the floats re positioned.
10:06:44 [dael]
Rossen: You'll have to show me the test case.
10:06:53 [dael]
??: top margin will collapse through?
10:07:00 [astearns]
10:07:01 [dael]
iank_: Yes.
10:07:32 [dael]
Rossen: dbaron did you get this into your head?
10:07:44 [dael]
dbaron: Kinda. There are a set of positions you can reject without layout.
10:07:51 [dael]
Rossen: What does 2.1 spec suggest?
10:08:17 [dael]
astearns: From my recollection when defining shapes, FF has the right behavior where you slide things until it fits.
10:08:33 [dael]
Rossen: What do you mean by slide? In fremy picture, would you consiter sliding?
10:08:41 [dael]
astearns: I recall line layout, not BFC.
10:08:52 [dael]
Rossen: line layout is regid.
10:09:03 [dael]
dbaron: Line layout has the same problem because the line can get longer.
10:09:13 [dael]
astearns: And trying them at a lower position can change the width.
10:09:23 [dael]
Rossen: [draws]
10:09:59 [dael]
Rossen: Assuming this geometry is what you have to play with (large multi tiered box) what do you mean by sliding?
10:10:52 [dael]
Rossen: Let's assume everything above is taken. First place you can position is here Then you arrive and get to some kind of layout. Is sliding on he x axis? one of the geometries?
10:11:24 [dael]
dbaron: For both line layout and BFC you have 2 nested loops. If you fail to fit....the outer loop is over your y position and the inner is over your reduction in width.
10:12:04 [dael]
dbaron: If you try and place here and fail because it intersects below you narrow your width to account for the intersection and try again. You go until you fit or you fail but there's no more floats.
10:12:38 [dael]
dbaron: That's the inner loop. Outer loop is we failed to find a width for this vertical position so then we move down to the next vertical position with more room.
10:13:01 [dael]
dbaron: In the simple case what we impl right now is look for next position where something changes.
10:13:13 [dael]
dbaron: Traditional floats it's not that bad, in shappes we should loop
10:13:34 [dael]
iank_: On shapes we switched shape sizes and BFC so shape has no effect on BFC.
10:13:49 [dael]
dbaron: I hink you can exclude a decent amount of things.
10:14:15 [dael]
astearns: Changing what you're doing depending on float or shape I don't think that makes that much sense. Everything you can do with hspaes you can do with floats.
10:14:26 [dael]
iank_: We have use counters saying it's not used so we switched it off.
10:14:26 [fantasai]
s/floats/sufficient number of floats/
10:14:54 [dael]
astearns: I'm not that concerned with BFCs but everything we're discussing as a problem for BFCs is also a problem for placing first line of non-BFC content next to lfloats.
10:14:59 [dael]
iank_: SLightly different.
10:15:18 [dael]
Rossen: In general what you desc makes sense. I hope there's a spec where we can define this. I failed to find anything when I impl.
10:15:21 [dael]
astearns: Section 9.5.1
10:15:36 [dael]
dbaron: 2.1 defines it for lines but not well for BFC is my memory.
10:15:58 [dael]
dbaron: All float rules in 2.1 are in terms on constraints and this is a case where constraints is a bad way of defining it.
10:16:12 [dael]
fremy: This is potentially a lot of layout.
10:16:29 [richr]
richr has joined #css
10:16:29 [dael]
iank_: In our new impl of block layout we went with FF behavior going through each oppotuniry.
10:16:39 [dael]
Rossen: From user POV tat's the better behavior.
10:16:49 [dael]
iank_: I can describe the 2 pass method.
10:17:20 [dael]
iank_: The 2 pass one is layout and the based on I think min-content you lay out in one of the areas.
10:18:46 [dael]
fremy: I proposed you first try the first position. Then you try the furthest right space. If it's bigger then the min-width you put the element there. That's what Edge is doing. I'm faily confident that'll work almost all the time and then you don't have to layout again and again. As an author you don't expect this to be super expensive, but it can be.
10:18:47 [rego]
this non-BFC example has overlapping issues on Blink/WebKit,css,output
10:19:43 [dael]
florian: If I understand dbaron in the case without minimum the extra part you compress. But if you have the minimum you have to do a re-layout.
10:20:28 [dael]
dbaron: Most expensive case is [whiteboards] a table and you're dealing with a shape that has a really rough uneven edge.
10:20:40 [dael]
dbaron: So you keep having to relayout.
10:20:52 [dael]
iank_: This is why we switched this off for shapes.
10:21:08 [ericwilligers]
ericwilligers has joined #css
10:21:09 [dael]
fremy: We only do this a few ties and then give up and overflow the floats.
10:21:35 [dael]
fremy: What this would do is it would try to lay it out and if it doesn't work it would put the table under the shape.
10:21:50 [dael]
astearns: I'm not sure the example of the narrowest place works for this example.
10:21:57 [dael]
dbaron: Depends on what the shape is.
10:22:19 [dael]
fremy: If the table fits it fits. If it's bigger it goes undermeath.
10:22:29 [dael]
myIes: I think the point is it's valid, but not good.
10:23:02 [dael]
astearns: I see the appeal from an impl side, but as an author I can't imagine wanting...if an author wants the content as far up in the layout as possible so FF and half of Chrome is what I expect an author would want.
10:23:19 [dael]
astearns: If we have to have a strategy to avoid re-layouts, giving up and going past the floar may be better.
10:23:25 [dael]
fremy: Chrome would like to remove this thing.
10:23:50 [dael]
iank_: We've removed shapes. WE added counters to shapes and barely saw usage. I believe shapes now only effect line-boxes.
10:24:12 [dael]
iank_: As people add lots of lfoats, sure. Shapes is easy to go into every max-length.
10:24:28 [dael]
dbaron: I think saying shape-outside doesn't effect BFC is a reasonable comprimise.
10:24:35 [dael]
astearns: We deferred to 2.1 in the spec.
10:24:40 [dael]
fremy: [missed]
10:24:55 [dael]
dbaron: I think wikipedia looks better with the algo.
10:25:10 [dael]
fremy: In most cases you do it in 3 which gets you same result.
10:25:22 [dael]
dbaron: It's reasonably common that the narrowest thing will be something narrow.
10:25:46 [dael]
astearns: Because we counter with shapes and BFCs is small, a different rule for BFC is fine. But I'd hate that to be preceident for line layout.
10:25:59 [dael]
iank_: That's easier because when you do the first pass you know the height.
10:26:12 [dael]
astearns: I don't mind as long as it doesn't apply to line layout.
10:26:20 [dael]
florian: Are you sure problem isn't for lines
10:27:02 [dael]
dbaron: You don't change height of the line depending on it getting narrower. If you shrink the line it might shrink, but it might not increase in height. If you shorten the line and it gets shorter in height, but it fits, you leave it.
10:27:10 [dael]
iank_: Always works in 2 passes.
10:27:22 [dael]
Rossen: And BFC the norrow you make it the longer it gets usually.
10:27:41 [dael]
dbaron: You can guar the shortening look is 2, the moving down can be more loops.
10:28:06 [dael]
fremy: 2 proposal. 1 to say BFC....
10:28:36 [dael]
Rossen: 1) Do all possible layouts which will optimize for the area.
10:28:59 [dael]
myles: 2) layout to widest. If it doesn't fix calculate some numbers and if it doesn't fix push it.
10:29:06 [dael]
myles: 3) is always push it.
10:29:18 [dael]
Rossen: We try and find space for the layout and then push it.
10:30:13 [dael]
fremy: Reason we're here is we've found 3 is not good on wikipedia.
10:30:28 [dael]
myles: 1 is what user wants. astearns pointed out option 3 may be better then option 2 for user.
10:30:34 [dael]
fremy: [missed]
10:30:49 [dael]
astearns: Option 1 will often find a > min place to put the BFC.
10:30:53 [dael]
fremy: Not as likely.
10:31:02 [dael]
dbaron: Depends on the floats.
10:31:45 [dael]
dbaron: If your floats are like this (smallest on top right) then you'll be find on the top.
10:32:01 [dael]
iank_: [whiteboards]
10:32:42 [dael]
Rossen: Can I make a proposal? I'm not sure we'll be able to resolve without wasting more paper. Holding the whole group on this prob. not very helpful. Let's take this over lunch with the people interested.
10:32:56 [dael]
Rossen: So what we believe is best for user and impl and we'll come back after the break.
10:32:58 [fantasai]
Iank drew two stepped sets of floats, one of decreasing widths on the left, on eof increasing widths on the right, leaving a diagonal channel
10:33:25 [dael]
dbaron: I think one resolution that solves part of the problem is the interaction with shapes and BFC. Prop: BFC flow around floats don't care about shape-outside.
10:33:52 [dael]
fremy: If you do shape-outside and you do a float BFC is wrong. If you do shape outside the entire element floats.
10:33:59 [dael]
florian: For FC it's rare enough it's okay.
10:34:00 [rachelandrew]
rachelandrew has joined #css
10:34:19 [dael]
Rossen: Shapes with BFC is probably not common. Shapes with text is how feature was intended.
10:34:28 [dael]
myles: why do we want this proposal
10:34:32 [dael]
iank_: Impl complex.
10:34:40 [dael]
dbaron: Gets rid of worst cases.
10:34:51 [dael]
myles: You just look at mins and maxes
10:35:00 [dael]
Rossen: Whatever you have with shape you can make with floats.
10:35:08 [dael]
dbaron: Okay, I take back that we might be able to resolve.
10:35:20 [dael]
Topic: end for now
10:35:40 [smfr]
smfr has joined #css
10:35:48 [dael]
<br type="lunch" dur="60min">
10:35:53 [dael]
return at 13:35
11:10:02 [dbaron]
dbaron has joined #css
11:22:29 [iank_]
11:25:46 [richr]
richr has joined #css
11:31:05 [rachelandrew]
rachelandrew has joined #css
11:31:58 [smfr]
smfr has joined #css
11:36:43 [myles]
myles has joined #css
11:37:17 [ChrisL]
ChrisL has joined #css
11:37:45 [Loirooriol]
Loirooriol has joined #css
11:37:57 [surma]
surma has joined #css
11:38:05 [dael]
Rossen: Let's resume
11:38:09 [ChrisL]
11:38:25 [fremy]
fremy has joined #css
11:38:48 [flackr]
flackr has joined #css
11:38:55 [dael]
Topic: Complex float shapes and bfc sizing
11:39:08 [dael]
11:39:58 [dael]
Rossen: This is the picture we were trying to illustrate on the white board. It's intended to illustrate the 3 proposals.
11:40:18 [dael]
action Rossen send the image of discussion to archives
11:40:19 [trackbot]
Created ACTION-872 - Send the image of discussion to archives [on Rossen Atanassov - due 2018-04-17].
11:41:06 [dael]
fremy: Proposal #3 is when you have an image that overflows you just push it down, but that was also leaving a lot of empty space. Edge is doing that right now.
11:41:31 [dael]
Rossen: We do one layout. We're assuming inline is in top left.
11:41:43 [dael]
astearns: BFC tried for full width and intersected with float.
11:42:07 [dael]
Rossen: Right. If we don't fit because we intersect we try and fit and end up at the bottom (behavior #3)
11:42:15 [dael]
florian: Width is full width of containing block?
11:42:34 [dael]
Rossen: Might not. It doesn't fit.
11:42:38 [dael]
fantasai: That's super weird.
11:42:42 [dael]
Rossen: And super performant.
11:43:03 [dael]
astearns: Edge is getting bugs on clearing and leaving the empty space above.
11:43:25 [fantasai]
Rossen was explaining that once they've cleared past the floats into a larger-width area, they don't lay out into that larger area but keep the width of the initial reflow
11:44:20 [fantasai]
This is what I thought was super weird
11:44:24 [dael]
Rossen: Say you have a div and a tiny 0 width float and then another smaller float. In this case there's a 0 width which we layout the BFC next to the 0 width. BUt it intesects with the smaller float. Then we slide the BFC down. Say it doesn't fit and then it's before the small float.
11:44:51 [dael]
Rossen: you can argue we can fix our bug with behavior #2 which has different drawbacks.
11:46:40 [dael]
fremy: Proposal #2 is if it doesn't fit you try one more layout. You try to find first place you can fit the min content of the BFC you're trying to place. If you can fix the min-content you put it there. Downside is you may end up in a situation where it goes down if the min-width is too small. You try to find somewhere you can fit the min width. It doesn't require any layout. It's a guar valid. Drawback is it could be min width is very small so yo uget very tall.
11:46:55 [dael]
florian: In this logic if there is several places you can fit do you try all?
11:47:15 [fantasai]
s/fix the min-content/fit the min-content and there are no floats limiting the height below it/
11:47:25 [dael]
iank_: The first one. In this case there's three areas. You start at the first and if it fits you put it there.
11:47:33 [dael]
fremy: If it doesn't you try the second and then the third.
11:47:44 [dael]
iank_: It's a 2 pass layout and you're trying all areas.
11:47:53 [dael]
astearns: It fixes the floated UI issue.
11:48:09 [dael]
fremy: Option 1 is Firefox. It's literally trying all possibilities.
11:48:35 [leaverou]
11:48:38 [dael]
fantasai: Nobody gets the rainbow where it is?
11:48:43 [dael]
Rossen: Firefox is rainbow.
11:49:00 [dael]
iank_: I posted a link at 1:22 pm of a test case for this.
11:49:15 [dael]
myles: rainbow is FF, 3 is edge, no one does 2.
11:49:24 [dael]
iank_: Blink and webkit is undefined.
11:49:48 [dael]
fremy: There's one thing I don't like is that.
11:50:09 [dael]
Rossen: People use offset flows. [missed] it's the only way to offset floats veritically.
11:50:40 [dael]
fremy: No gap here (position the float, the then BFC) means that someone really wanted that space.
11:51:08 [dael]
astearns: So we have 3 which goes below the floats. 2 which makes and attempt based on heuristics and 1 which does the best but is expensive.
11:51:19 [dael]
fremy: Also will Chrome disable this for shapes.
11:51:35 [dael]
astearns: Rossen said there was a conclusion.
11:51:40 [dael]
fremy: [missed]
11:51:55 [dael]
group decision: no conclusion
11:52:07 [dael]
fremy: If people won't agree on #2...I thinkw e should resolve on 2.
11:52:21 [dael]
Rossen: 2 is improvement for us and Chrome and reduced experience in FF.
11:52:42 [dael]
iank_: The test case I dumped in IRC we do 2 in.
11:52:48 [gsnedders]
what test case?
11:53:06 [dael]
astearns: Would anyone objec to spec the second option?
11:53:09 [dael]
dbaron: Who does it now?
11:53:10 [gsnedders]
12:22 < iank_>
11:53:14 [dael]
many: no one
11:53:21 [dael]
dbaron: I would object to spec something no one does.
11:53:39 [dael]
fremy: We can't spec what Chrome is doing. Firefox is option 1. That's better then our version.
11:53:44 [dael]
astearns: Sounds like we don't agree.
11:53:52 [dael]
iank_: WE can see how expensive 1 is.
11:55:01 [dael]
Rossen: We can resolve on 1, ask whomeever impl it to spec it. If this is performance we can ask to get some data back. In the meantime other impl...we'll do something to fix. For normative behavior it's hard to argue #1 isn't the best. It's up to us to figure out easy engineering tricks to optimize as much as possible.
11:55:08 [dael]
Rossen: So is there objections to #1?
11:55:11 [dael]
fantasai: Sounds better.
11:55:20 [dael]
astearns: Objections to spec #1 for BFCs?
11:55:29 [dael]
fremy: No special about shapes?
11:55:36 [dael]
Rossen: No, nothing special about shapes.
11:55:48 [Karen]
Karen has joined #css
11:55:48 [dael]
astearns: If we spec we'd need a floats module.
11:56:11 [dael]
Rossen: Let's get a resolution about the behavior we want.
11:56:24 [rego]
11:57:02 [dael]
astearns: Prop: The working group preference is to specify BFC float avoidance behavior to match what is spec in 2.1 for inline layout float avoidance behavior
11:57:04 [dael]
Rossen: ish.
11:57:15 [dael]
astearns: To follow those guidelines and spec it well.
11:57:19 [dael]
astearns: Obj?
11:57:39 [dael]
RESOLVED: The working group preference is to specify BFC float avoidance behavior to match the guidelines of what is spec in 2.1 for inline layout float avoidance behavior
11:57:44 [dael]
Rossen: Where does this go?
11:57:47 [dael]
florian: 2.1?
11:57:56 [dael]
astearns: I think floats module. 2.1 is vague on inline.
11:58:18 [dael]
Rossen: In CSS positioning the fork happened for floats and position.
11:58:35 [dael]
fantasai: I'd rec not in the same module because psoitioning and floats are quite divergent.
11:58:48 [dael]
Rossen: That's okay. We can take the line out of 2.1 and start a module.
11:58:58 [dael]
Rossen: A resolution for that?
11:59:09 [plh]
plh has joined #css
11:59:11 [dael]
gsnedders: If we're removing a line from 2.1 we should have a resolution.
11:59:22 [dael]
astearns: We're not taking out, we're making a module to refine.
11:59:41 [dael]
astearns: objections to someone creating a css float module at some point?
11:59:50 [dael]
Rossen: I can create the fork and start it.
11:59:56 [dael]
dbaron: I can help, but I don't want to be only person
12:00:16 [dael]
astearns: objections to rossen and dbaron creating a css float module?
12:00:37 [dael]
smfr: This isn't about float layout, but wrapping behavior. So if shapes trigger same behavior doesn't make sense.
12:00:50 [dael]
astearns: Shape outside is in relation to floats and exclusions would tie in.
12:00:58 [dael]
fantasai: I think floats is right place.
12:01:15 [dael]
dbaron: I think if I'm putting it with something it would be block layout and that doesn't really have a L3 for that.
12:01:44 [dael]
myles: That's better then proposal. Rather then a new spec we should have someone take up stewardship of the block layout
12:01:53 [dael]
fantasai: It has more stuff in it.
12:02:18 [dael]
astearns: Like with any other module the bits and pieces that refer to other specs say it's defined over there.
12:02:39 [myles]
myles has joined #css
12:02:42 [dael]
astearns: Can be floats module, can be wrap. They're pretty synonymous for css so I don't care on the name.
12:02:53 [dael]
Rossen: Floats is more specific and targeted.
12:03:15 [dael]
astearns: Prop: Start a CSS 3 Floats Module with dbaron and fremy as co-editors
12:03:22 [dael]
RESOLVED: Start a CSS 3 Floats Module with dbaron and fremy as co-editors
12:03:31 [dael]
Topic: end
12:03:41 [dael]
astearns: We have layout stuff this afternoon.
12:03:43 [dael]
Topic: grid
12:03:52 [dael]
Topic: Review state of Grid Level 2, figure out next steps
12:04:19 [fantasai]
12:04:23 [dael]
fantasai: Issue with grid L2 it has some proposals and no feedback. I can do anything to go forward
12:04:35 [dael]
fantasai: Open issues are like here's 2 proposals for subgrid, which do we want?
12:05:18 [dael]
fantasai: I wanted to bring this up because there's strong requests from the community to do this, but the spec for subgrid is there's 2 specs for subgrid. I don't know what to do next.
12:05:47 [dael]
florian: Is there author feedback?
12:06:54 [dael]
rachelandrew: I have feedback. Authors really want subgrid. The use cases I've seen are tied to dimension sub grid....the proposal that was pulled from L1 wouldn't solve them. People want the columns to be the sub grid. They don't want to define the rows. Having to locked to both dimenstions would be more frustrating then useful. Things I"ve seen assumed one dimension.
12:07:02 [dael]
fantasai: Proposal is to resolve on per axis subgrids.
12:07:08 [dael]
Rossen: Didn't we decide in tokyo?
12:07:16 [dael]
tantek: We added it as a possibility in tokyo.
12:07:27 [dael]
Rossen: sgtm. I thought we did that.
12:07:40 [dael]
Rossen: This is the 1.5 dimension model?
12:08:31 [dael]
fantasai: No, the way we set thing sup there's not many changes from one version to the other. Differences are in green. Main change is for per axis you need to ensure that if you're interweving the algo of the parent and child grids.
12:08:48 [dael]
fantasai: Algo is all defined. That's where spec is at. I think it's complete mostly.
12:08:52 [dael]
astearns: Do we have impl?
12:09:00 [dael]
fantasai: I don't think anyone is working on sub grids.
12:09:22 [dael]
TabAtkins: Mats was interested and opposed the non-per axis. That's what Igalia part impl.
12:09:31 [dael]
rego: We didn't impl anything yet.
12:10:00 [tantek]
Mats is working on it, see the Firefox subgrid meta bug (with dependent implementation bugs)
12:10:06 [dael]
fantasai: Syntatic difference the per axis has a subgrid keyword on grid-template-rows and grid-template-columns. Just one was a keyword on grid-template.
12:10:17 [dael]
astearns: Would anyone object to single axis subgrid?
12:10:26 [dael]
TabAtkins: No one has described how to do it yet.
12:10:37 [dael]
fantasai: It's in the spec. Here's the algo (section 2.4)
12:10:48 [dael]
astearns: It's spec as a diff to a doc with both.
12:11:01 [dael]
fantasai: It inlines everything in. It just has two colors of ink.
12:11:20 [dael]
astearns: Anyone besides TabAtkins have concerns on single axis subgrid.
12:11:51 [dael]
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.
12:12:34 [dael]
rachelandrew: I brought use cases to the last F2F but I rarely see something from an author that works for double axis. An ecommerce site that has a template where they want it to work no matter if there's 2 rows or 6 rows of stuff.
12:12:42 [dael]
rachelandrew: Let me see if I can find the examples
12:12:57 [dael]
astearns: Would people object to 2 axis subgrid?
12:13:07 [dael]
florian: I think rachelandrew would.
12:13:10 [rachelandrew]
12:13:50 [dael]
astearns: I'm hearing some people for and against single axis subgrid but I haven't heard opinions on 2 axis besides everyone thought it was too hard to get to for the first level of grid.
12:14:06 [tantek]
IIRC, all variants of subgrid were too much for grid level 1
12:14:51 [rachelandrew]
this is a better view, some examples
12:15:24 [dael]
Rossen: I still agree it was a good move to hold it back. To your second point as to if one or two axis is what we want, now that we can reason about it and think hoelistically the one axis is an easy shortcut to cover some use cases but during Tokyo I heard enough compelling reasons to have the per axis. I will admit I haven't reviewed 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.
12:15:45 [dael]
astearns: Perhaps we could leave it at peole should review the spec and look at the use cases and then come back soon?
12:15:58 [dael]
rachelandrew: I could probably get more use cases now that people are using grid.
12:16:08 [dael]
astearns: Is there an issue for choose which appoach?
12:16:10 [dael]
fantasai: Yep.
12:16:16 [fantasai]
12:16:22 [fantasai]
12:16:23 [dael]
astearns: I suggest we continue discussing in that issue.
12:16:34 [dael]
astearns: Anything else?
12:16:39 [dael]
fantasai: Whe do we want to return?
12:16:43 [dael]
Rossen: End of F2F.
12:16:57 [dael]
astearns: WE can try and bring this up end of Thursday. Then perhaps we can make a decision.
12:17:10 [dael]
astearns: Please take breaks or lunch time if as you read you have questions.
12:17:26 [dael]
dbaron: Would it help to get someone on a call.
12:17:35 [dbaron]
12:17:39 [dael]
fantasai: It would be good to have Mats look and reply on github.
12:17:46 [dael]
fantasai: I haven't heard from him.
12:17:57 [dael]
dbaron: If you want me to poke him can you send me what you want me to do?
12:18:04 [dael]
fantasai: Review the spec and comment.
12:18:14 [dael]
florian: Also express a preference? Or he always has.
12:18:17 [fantasai]
fantasai: And if there's nothing wrong with it say it's good
12:18:25 [dael]
astearns: Other part of grid L2 as aspect ratio contols
12:18:57 [dael]
12:19:16 [astearns]
12:19:22 [astearns]
topic: gutters
12:19:29 [astearns]
12:19:41 [dael]
fantasai: We resolved to add this to the first level of the WD. Just a request for people to let me know.
12:19:50 [dael]
TabAtkins: Other then that I want a unit on these I think it looks great.
12:20:16 [dael]
fantasai: unit proposed is ar unit for aspect ratio
12:20:37 [dael]
astearns: Two options are a bare number or an ar unit
12:20:43 [dael]
fantasai: I'm open to name suggestions
12:20:53 [dael]
TabAtkins: I regret not putting unit on flex.
12:21:03 [dael]
astearns: Could ar be used in other places?
12:21:10 [dael]
TabAtkins: A generic aspect ratio
12:21:16 [dael]
florian: It's mathematically unitless.
12:21:23 [dael]
fantasai: It's a multiplier.
12:21:31 [dael]
TabAtkins: Whatever the other thing results in multiply it.
12:21:42 [dael]
florian: Does the unit thing play into if we want to ever use calc on it.
12:21:44 [dauwhe]
dauwhe has joined #css
12:22:39 [dael]
TabAtkins: Numbers tend to cause parsing issues. It causes issues on the flex things. I'd prefer not to keep that. This has a specific meaning so it should be tagged in a specific way. agnles are just numbers.
12:22:41 [dael]
fantasai: They're not.
12:22:52 [dael]
TabAtkins: They're radians which are just an ID.
12:23:07 [dael]
fantasai: Somewhat releated discussion has been aspect ratio units needed, #1173
12:23:08 [ChrisL]
how are radians an ID?
12:23:45 [dael]
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. Question was if there isn't an element can you asign the aspect ratio property.
12:23:55 [TabAtkins]
ChrisL, Radian is (length of arc) / (length of radius), which is unitless
12:24:23 [ChrisL]
an aspect ratio is (by definition) a ratio. It is a length divided by a length, and thus also unitless.
12:24:36 [dael]
fantasai: You might decde you have a bunc hof fr columns and you want the rows to be 1:1. Once we add this 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.
12:24:47 [dael]
astearns: The only things in having that row were spanning it would be weird.
12:24:58 [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.
12:25:14 [dael]
fantasai: One proposal was to have an ar unit in grid template columns that would represent the aspect ratio multiplied by the axis. QUestion was what if they are different sizes
12:25:25 [dael]
fantasai: Proposal I had is 1ar is always 1fr in the other.
12:25:35 [dael]
florian: You can't map to a colum 'cause you don't know which ot match.
12:25:41 [dael]
fantasai: I'ts not clear what we need to do.
12:25:47 [dael]
astearns: And a side discussion.
12:25:52 [dael]
fantasai: A unit may be useful in this case.
12:26:01 [ChrisL]
remember though that whenever we add units, it stops those things being used in custom properties, because we can't divide by united values
12:26:02 [dael]
astearns: So do you want to resolve to add a ar unit?
12:26:12 [dael]
TabAtkins: If we accept hte gap syntax I feel we should have a unit.
12:26:29 [dael]
ChrisL: Remember when we add units you can't use them in custom properties. You can't devide by an ar.
12:26:37 [dael]
TabAtkins: You can, ot works now.
12:27:12 [dael]
astearns: Objections to adding an ar unit to the grid 2 spec for align content and justify content?
12:27:22 [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.)
12:27:24 [dael]
RESOLVED: add an ar unit to the grid 2 spec for align content and justify content
12:27:41 [dael]
topic: end
12:27:41 [dael]
astearns: Anything else on grid 2?
12:27:52 [ChrisL]
fair enough; would be good to see that agreement in the spec, and implemented
12:28:03 [dael]
fantasai: It's just those 2 things. Once we have agreement on subgrid and someone has read it I'd be happy to request CR.
12:28:21 [dael]
astearns: I'd like to get an impl started. I'd like to see progress on grid area styling proposal.
12:28:54 [dael]
fantasai: That's grid 3. grid 2 is just these small things. Styling of grid areas is more complex impl-wise. In terms of figuring out the spec that'll be harder.
12:29:09 [fantasai]
s/these small things/subgrid and this one other small thing/
12:29:22 [fantasai]
s/impl-wise/spec-wise for sure (uncertain about impl-wise)/
12:29:24 [dael]
Topic: Can the sizing algo be made to deal with this
12:29:32 [dael]
12:29:37 [florian]
12:30:08 [dael]
florian: I was laying out a page of manga using grid so each cell is a grid. It should layout like ^
12:30:20 [florian]
12:30:24 [dael]
florian: Defining a bunch of columns and rows and everything can fit, but it's manual.
12:30:28 [dael]
florian: Here's what you get ^
12:30:46 [dael]
florian: It has unneeded empty spaces.
12:31:41 [TabAtkins]
Very simple example:
12:31:56 [dael]
florian: I think this boils down to current sizing algo not considering enough things. It's descried as a possibly improvable heuristic. If we agree this is a good thing to sounds desireable...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.
12:32:00 [dael]
TabAtkins: Simple example ^
12:32:40 [dael]
TabAtkins: [explains example] We take the largest of the planned increases so we're not loosly wrapping each item. Ideal would be the latter image. It's one possible version.
12:32:54 [dael]
florian: I believe an algo exists that we could solve it, or are we too locked into compat.
12:33:36 [dael]
fantasai: I think we should be able to make the adjustments. 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.
12:33:56 [dael]
florian: I might be able to research the thoroetical algo but I'm not righ to say if impl-able.
12:34:15 [dael]
fremy: I've been working on some layouts and you can do a post-process to reduce the sizing.
12:34:48 [dael]
TabAtkins: This example (bottom of link) it shows one possible switch. BUt there's several ways to solve it like making the column 300 and the last one goes to 0.
12:35:04 [dael]
florian: Some examples have a range of solutions, mine has one solution.
12:35:40 [dael]
florian: I think it's worth looking into if there's a general option that we're not blocked in. I'd appriciate a mathematically inclided person to help. Maybe do the current algo and squish would work. I
12:35:56 [dael]
fremy: browsers are impl grid and we don't want to change whole algo so that's easier.
12:36:21 [dael]
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.
12:36:54 [dael]
fantasai: TabAtkins and I can take an action to look at post-processing step to see if that works. Maybe send a email to bert with a link to this issue to see if he has some insight.
12:37:14 [dael]
ChrisL: We was talking to people from Monash (sp?) univeristy with expertese.
12:37:14 [TabAtkins]
s/making the column 300 and the last one goes to 0/making the columns 50,250,0, which is a big change from the current way they lay out/
12:37:35 [dael]
fantasai: We also had Caesar (sp?) who was working on an impl of Bert's grid spec.
12:37:35 [ChrisL]
12:37:44 [fantasai]
12:38:19 [Rossen]
dael, here's the illustration that should go with the BFC discussion (issue 2452)
12:38:25 [ChrisL]
s/Monash (sp?)/Monash/
12:38:26 [dael]
florian: I think the trickier part is that this is more complicated. If we have auto sizing it's simplier. 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.
12:38:38 [dael]
astearns: Anything more?
12:38:43 [dael]
florian: Nope.
12:38:51 [dael]
Topic: Grid track sizing items spanning a flexible track
12:38:59 [dael]
12:39:48 [dael]
rego: Quite related, You have an item that spans 2 columns. One of them is outside it's flexible track and we weren't sure what would be the best result. We're not sure what's the core approach. Rossen was tyring to clarify in the last comment.
12:40:27 [dael]
astearns: There's a specific tweak to the algo you propose?
12:40:53 [dael]
rego: Original algo was aligned that you don't expand a track with a flexible track sizing. Maybe we can open the use cases.
12:41:21 [dael]
fantasai: We should try Rossen suggestion in the issue and see if it works. I haven't fully through it through but that's what I'd want to try.
12:42:17 [dael]
Rossen: When we looked we played with magizine layouts. One recurring thing was when you have a splash page when an item that spans x 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.
12:42:44 [dael]
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.
12:42:50 [dael]
fantasai: Makes sense to me.
12:43:00 [dael]
astearns: Do we need a resolution to edit in Rossen proposal?
12:43:13 [dael]
fantasai: Resolution to add Rossen proposal and we'll revisit
12:43:26 [fantasai]
s/revisit/revisit if there's a problem/
12:43:27 [dael]
RESOLVED: edit in Rossen proposal in
12:43:40 [dael]
Topic: 'justify-content' other than 'normal' or 'stretch' should change column count/size rules
12:43:52 [dael]
12:44:00 [dael]
astearns: We've discussed in the past.
12:44:15 [dael]
TabAtkins: As florian says from third to last comment, right place to start reading is the one above.
12:44:23 [fantasai]
12:44:56 [dael]
TabAtkins: florian obj to current spec are 3. 1) in current spec you can't robustly fix the ratio of the defualt column gaps
12:44:58 [dael]
florian: fixed that
12:46:00 [dael]
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 incolve special cases multii col if the column gap and so we'd be against that.
12:46:04 [fantasai]
sorry link to comment is
12:46:21 [dael]
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 unreadbale.
12:46:28 [dael]
TabAtkins: Then you set padding.
12:47:31 [dael]
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 multi col has text, though,a nd if you don't have roon you fallback to block which is good. BUt if you're forcing padding for space you keep the padding when you collapse.
12:48:40 [dael]
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 colum that you don't want the 1/2em gap. You put it there for a reason and I don't see why it goes away. It goes away in multi col because it has no gaps, UBt you're explicitly putting the gaps.
12:48:56 [dael]
TabAtkins: If a single column you want the text flush you'd want that in many columns.
12:49:19 [dael]
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.
12:49:30 [dael]
fantasai: I'm opposed to different map between multicol and flex.
12:49:42 [fantasai]
s/I'm/Regardless, I'm/
12:49:48 [fantasai]
12:49:51 [dael]
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.
12:49:52 [fantasai]
12:50:05 [fantasai]
s/space between/space-between/
12:50:12 [dael]
rachelandrew: I agree we want to be able to maintain the 1em so people don't set column-gap to 0.
12:50:52 [dael]
florian: This issue traces back to before we merged the models. Now we have. i'm okay with what you proposed, we jsut never discussed it. It was just added to the spec. If everyone agrees.
12:51:06 [dael]
fantasai: Prop: Alignment and gaps in multicol behave exactly like grid.
12:51:12 [dael]
astearns: Close no remaining changes.
12:51:23 [dael]
TabAtkins: I could go with a note for how it works.
12:51:42 [dael]
fantasai: I think people know how to do padding. They figured it would for grid so you'd have to have anot ein both.
12:52:19 [dael]
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.
12:52:51 [dael]
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.
12:53:16 [dael]
astearns: Prop: 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
12:53:19 [dael]
astearns: Obj?
12:53:33 [dael]
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
12:53:40 [dael]
Topic: axis names
12:53:48 [dael]
12:54:54 [dael]
fantasai: SelenIT commented that rachelandrew article 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 spaces and since most people learn grid from rachelandrew it's probably better to match her.
12:55:32 [dael]
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.
12:55:51 [dael]
fantasai: 3 options. 1 is don't change the spec 2 flip to match rachelandrew 3 remove termonology.
12:56:16 [fantasai]
Reasoning for the spec is in
12:56:30 [dael]
TabAtkins: I'm in favor or removing the termonology. 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
12:56:33 [fantasai]
terminology is in
12:56:39 [dael]
rachelandrew: I prefer block and inline.
12:57:08 [dael]
Rossen: rachelandrew can you fix and teach people the way we have intended this to be spec?
12:57:15 [dael]
rachelandrew: I'd prefer us to use block and inline.
12:57:28 [dael]
Rossen: I think it's fine but also spec what the row and columns are correctly.
12:57:37 [dael]
fantasai: Note that the axis names appear 3-5 times total.
12:58:23 [dael]
Rossen: I'm slightly opposed because the column 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 nec the same.
12:58:28 [dael]
fantasai: Exactly the same.
12:58:38 [dael]
fantasai: Question...which is the row axis? Horz or vert?
12:58:53 [dael]
Rossen: Vertical.
12:58:59 [dael]
fantasai: It's horizontal in the spec.
12:59:11 [dael]
fantasai: If we want to match your head we need to flip.
12:59:15 [myles]
myles has joined #css
12:59:18 [dael]
Rossen: Row is if you add more rows so it's how it advance.
12:59:27 [dael]
plinss: Thing you put in a row progress horizontally.
12:59:42 [dael]
astearns: I hear these terms aren't used much in the spec. What damange does removal cause?
12:59:56 [dael]
TabAtkins: Every time we use the terms we also call it block or inline in parans.
13:00:06 [dael]
fantasai: There's no occurance of these terms where both aren't used.
13:00:15 [dael]
astearns: Usless terms. Cause confusion. WE should remove.
13:00:25 [ChrisL]
13:00:26 [dael]
RESOLVED: Remove these terms from the grid spec
13:00:39 [dael]
Topic: Alignment
13:00:47 [dael]
Topic: Closing out last few open issues and republishing
13:00:54 [rego]
the last comment in previous issue:
13:01:01 [dael]
Issues list:
13:01:10 [smfr]
smfr has joined #css
13:01:17 [fantasai]
13:01:30 [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
13:01:36 [fantasai]
Topic: calc() with percentages in margins/padding
13:01:41 [dael]
13:01:42 [fantasai]
13:01:44 [fantasai]
rego: no
13:02:00 [rego]
fantasai: :)
13:02:19 [smfr]
smfr has joined #css
13:02:47 [dael]
fantasai: it was to discuss 0ing out a % vs the entire expression. Example calc (10% + 10px) 0ing the entire expression is what's impl. 0ing the % is more meaningful. This is for purpose of calc intrinsic size calc of element.
13:03:09 [dael]
dbaron: It's also continuous in terms of what happens when you have a calc that approaches 0 and you remove the calc.
13:03:19 [fantasai]
Comment summarizing issue:
13:03:29 [dael]
TabAtkins: Are we okay with some properties having a different indefinite percent with calcs.
13:03:36 [dael]
fantasai: I prefer 0 out the %
13:03:47 [dael]
florian: Justification to 0 everything other then it's what we have
13:03:51 [dael]
fantasai: Id din't hear anything.
13:04:21 [dael]
Rossen: I agree with fantasai. 0ing the % makes more sense. Having a box model with tabbing and you'll 0 out %
13:04:51 [dael]
fantasai: For size we ignore entire calc. We closed that in #1132. SOrry,w e throw out the calc and treat as auto. Fallback to initial value
13:05:26 [dael]
fantasai: That makes snese for sizing in a way it doesn't here is if you fallback to the original that has some kind of meaning. In this case there's no meaningful value for margins and padding.
13:05:45 [dael]
astearns: In only 0 out % for calc that's not sizing it's a slight descrepency.
13:05:48 [dael]
fantasai: correct.
13:06:12 [dael]
florian: We can do calc of 10%+10px is the same as 10px but we cant do auto+10px because that's not defined.
13:06:24 [Rossen]
s/Having a box model with tabbing and you'll 0 out %/Having a box model with some % and non-% values results in the same logic, where we would zero out the % values and add the rest of the defined sizes/
13:06:41 [dael]
astearns: Arguments against only 0ing out % on non-sizing use of calc
13:06:44 [dael]
astearns: Obj?
13:06:47 [fantasai]
(Florian was responding to Alan's question of why we throw out the expression for sizing props)
13:07:07 [dael]
RESOLVED: zero out percentages on non-sizing use of calc
13:07:12 [dael]
Topic: end
13:07:26 [dael]
fantasai: We're waiting on dbaron to get back to us on a pile of Alignment issues.
13:07:34 [dael]
fantasai: #1611 is open
13:07:44 [fantasai]
13:08:11 [dael]
Topic: Should last-baseline's fallback alignment be safe or unsafe?
13:08:19 [dael]
13:09:05 [dael]
fantasai: You have a flexbox and inside you have items with last-baseline alignment but the flexbox is less then you need we have to decide how to align them. Just like for first baseline you align and then start align at the top.
13:09:51 [dael]
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 overflow the top or do we take the things that are too big and put them at the bottom and they no longer participate in base alignment.
13:10:09 [dael]
astearns: From I can access and read safe is better, but from design unsafe is better.
13:10:20 [dael]
myles: impl difference.
13:10:26 [dael]
fantasai: We were generally unsure before.
13:10:32 [dael]
myles: have we asked authors?
13:10:50 [dael]
florian: Can we default to safe? Default ing to safe sounds...safer? And let authors opt-in.
13:11:06 [dael]
TabAtkins: We don't let you set it. It seemed like more switches then you needed access to.
13:11:17 [dael]
fantasai: We could make it possible to combine the keywords.
13:11:31 [dael]
florian: I'd prefer default safe and have the keyword.
13:11:56 [dael]
astearns: We last left this that someone would write a blog post.
13:11:59 [dael]
fantasai: That was not done.
13:12:25 [dael]
astearns: I don't think we should assume we will add a switch. we should decide based on probablility that this is a weird edge case so it's not worth our time to have a switch.
13:12:30 [dael]
TabAtkins: That's why we haven't done it.
13:12:59 [dael]
Rossen: Can we resolve on choosing safe? If someone squeaks really hard we'll solve it.
13:13:14 [dael]
astearns: Objections to using the safe behavior in this case of last-basline alignment?
13:13:24 [dael]
fantasai: All using the alignment properties.
13:13:51 [dael]
astearns: In this case with content that will not fit in it's container and we faill to be able to last baseline align things things will overflow in a safe direction.
13:14:00 [dael]
RESOLVED: 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.
13:14:03 [dael]
Topic: end
13:14:14 [dael]
fantasai: New WD once dbaron says they're okay?
13:14:39 [dael]
astearns: Objections to new WD once we get through some of the remaining open issues?
13:15:01 [dael]
ChrisL: I'd rahter be told when it's approved, not we approve some time in the future.
13:15:10 [dael]
Rossen: Let's publish now and again later.
13:15:15 [dael]
astearns: WE just resolved 2 things.
13:15:19 [dael]
fantasai: One was no changes.
13:15:30 [dael]
Rossen: The one for calc was in sizing?
13:15:44 [dael]
astearns: Objections to publishing a new WD of Alignment with the one edit from the earlier resolution.
13:15:57 [dael]
RESOLVED: Publish a new WD of Alignment with the one edit from the earlier resolution.
13:16:12 [dael]
<br type="short">
13:39:03 [dael]
astearns: We should get started again.
13:39:56 [dael]
Topic: Sizing
13:39:58 [dael]
Topic: Does indefinite min-height: N% fall back to zero or auto?
13:40:05 [dael]
13:41:08 [dael]
TabAtkins: This is for min-width and height. Do they fallback to auto or 0? General rule is we fall back to initial value. Is that 0 or auto? Initial used to be 0, changed to auto.
13:41:28 [dael]
TabAtkins: 2.1 explicitly says they're treated as 0, but it was prob on the assumption 0 was the initial value.
13:41:48 [myles]
myles has joined #css
13:41:51 [dael]
TabAtkins: Only real case is you have a flex item and you can't resolve the min-height should it be auto or 0?
13:41:59 [dael]
TabAtkins: I'm of the opinion it hsould be auto.
13:42:04 [dael]
Rossen: Current?
13:42:12 [dael]
TabAtkins: 0 which was previous initial value.
13:42:32 [dael]
TabAtkins: Change to be consistent with the change to initial.
13:42:41 [dael]
fantasai: I'm trying to wrap my head around when this would be different.
13:43:01 [dael]
astearns: Last time we discussed 0% when we said it should be 0 it's different on width then min-width.
13:43:12 [dael]
fantasai: auto for width isn't hte same as min-width.
13:43:24 [dael]
astearns: We could throw out the calc on min-width if it's doesn't resolve.
13:43:38 [dael]
TabAtkins: either the percent 0s out or we throw it out.
13:43:42 [dael]
fantasai: Makes more sense.
13:43:58 [dael]
tantek: Treat min-width and min-height the same as we just resolved to deal with percentages.
13:44:05 [dael]
astearns: So it's 0 rather then auto.
13:44:27 [dael]
TabAtkins: Still a change from current. calc is replaced with 0. Current is calc(10%+10px) = 0. Now it's =10px.
13:44:41 [dael]
fantasai: This makes the most sense. Consistent with margins and padding.
13:44:57 [dael]
fantasai: If you set min-width to a non-auto size you're not expecting it to look at content
13:45:12 [dael]
astearns: Prop: treat indefinete % in min-width and min-height as 0
13:45:26 [dael]
RESOLVED: treat indefinite percentages in min-width and min-height as 0
13:45:31 [dael]
Rossen: This is web compat?
13:45:43 [dael]
TabAtkins: If you have a complex calc it's a change. percent only is the same.
13:45:53 [dael]
Topic: Adding a 'size' shorthand for 'width'/'height'
13:46:01 [dael]
13:46:36 [dael]
fantasai: Shorthands are nice. We have them for many things, but not combo of width and height.
13:47:14 [dael]
fantasai: We hadn't added that because there's a size property like thing that the app page has tht does not behave anything like this shorthand would. That sets the size of the writing box.
13:47:53 [dael]
fantasai: Options are do something wierd where size doesn't work for @page. Other option is some other word then size. "box-size" is the current issue in the suggestion.
13:48:10 [dael]
fantasai: It would be for block-size and inline-size. min-box-size would be the other.
13:48:20 [dael]
florian: Naming conflict is that bad?
13:48:37 [dael]
fantasai: It's a descriptor but operating on a box that accepts other boxes. It'll be weird forever.
13:49:05 [dael]
TabAtkins: Weird because page takes width and height and size should be a property there. Conflict itself is weird but especially in the exact case.
13:49:17 [dael]
TabAtkins: box-sizing is close.
13:49:29 [dael]
dbaron: box and block might be confused by some.
13:49:37 [tantek]
13:49:46 [dael]
Rossen: What is the motivation here?
13:49:58 [dael]
TabAtkins: People want to set width and height together.
13:50:12 [dael]
florian: When people want to says omething different they repeat themselves.
13:50:30 [dael]
fantasai: It's likely you'll want both to a keyword like auto or 100% or contain.
13:50:37 [dael]
TabAtkins: Equal sizing is reasonable.
13:50:51 [dael]
Rossen: The short shorthand is always going to give you squares.
13:51:03 [dael]
florian: If you do % it will not.
13:51:19 [dael]
TabAtkins: Unless box-size 50% is same for height and width.
13:51:27 [dael]
fantasai: If we didn't have a naming conflict this would be in the spec.
13:51:41 [dael]
florian: I'd ignore the naming conflict and say you can't use it in @page rule
13:51:54 [dael]
astearns: I don't like that because if you don't know anything about @page it's surprising.
13:52:13 [dael]
astearns: Here I've found I have to use it and the styles I set up perfectly are no longer good.
13:52:26 [dael]
florian: It's the code you wrote to size the page that would be weird.
13:52:27 [fantasai]
@page { size: 8.5in 11in; }
13:52:33 [dael]
rune_: Page doesn't match any elements?
13:52:37 [dael]
florian: no
13:52:44 [fantasai]
@page { size: letter; }
13:52:47 [dael]
astearns: I'm thinking copying from another container.
13:53:00 [dael]
emilio: I think having a shorthand for page rule isn't worth it.
13:53:23 [dael]
plinss: First comment TabAtkins said is people have been asking for this and it would be mildly useful. I'm not sure mildy is worth it.
13:53:34 [dael]
fantasai: I've had people bug me for this. Those people are not sitting here.
13:53:46 [astearns]
13:54:04 [emilio]
s/a shorthand/a special-case for @page rule/ above
13:54:25 [dael]
astearns: I'm not hearing consensus on using size or another name. I'm not hearing huge enthusiasm for solving this
13:55:01 [dael]
astearns: Might be worth a note in the spec saying we've considered a shorthand and have not found enough motivation for dealing witht he problems and outline what the problems are.
13:55:07 [dael]
astearns: Objections?
13:55:21 [dael]
RESOLVED: Add a note to the spec explaining this problem and move this issue to level 4
13:55:44 [dael]
Topic: Flexbox
13:55:51 [myles]
myles has joined #css
13:56:00 [dael]
Topic: sizing
13:56:09 [dael]
florian: Do we need a new WD?
13:56:11 [dael]
fantasai: Sure
13:56:23 [dael]
astearns: Obj to a new WD of Sizing with all current resolutions edited in?
13:56:28 [tantek]
13:56:33 [dael]
RESOLVED: Publish a new WD of Sizing with all current resolutions edited in
13:56:37 [dael]
Topic: Flexbox
13:56:40 [dael]
Topic: Min-content of shrinkable flex items
13:56:49 [dael]
13:57:09 [dael]
TabAtkins: We made some edits and we need to WG to approve.
13:57:15 [dael]
Rossen: Can you go over the edits?
13:57:17 [fantasai]
13:57:40 [dael]
TabAtkins: Last comment in the issue has a link to the change
13:57:47 [dael]
fremy: I need to process it.
13:57:57 [dael]
astearns: Anyone else want a summary?
13:58:34 [projector]
projector has joined #css
13:58:38 [dael]
Rossen: Let's get back tomorrow. I want to look as well b/c I spent time working on this issue. We had a change fixing some edge inconsistencies with this problem. We have to back it out because it seemed others were inconsistant.
13:58:48 [dael]
fantasai: We went with dholbert's solution over fremy.
13:58:59 [Rossen]
Rossen has joined #css
13:59:02 [dael]
astearns: There's a 2nd layout section Thursday morning. Let's add this then
13:59:11 [dael]
Topic: Table flex items with main size less than preferred intrinsic width
13:59:18 [dael]
13:59:22 [liam]
liam has joined #css
13:59:30 [shans]
shans has joined #css
13:59:59 [sylvaing]
sylvaing has joined #css
14:00:02 [dael]
TabAtkins: If you have a table that's flex item the flex sizing algo tells it what size to be but that's can be smaller then the table's min size. What happens? Edge and FF only use table sizing algo. Chrome flexes the table, but I'm not sure if it flexes more then minimum size.
14:00:16 [dael]
TabAtkins: fremy says table should flex and overflow to it's min size. I agree.
14:00:37 [dael]
astearns: Anyone disagree that tables flexed to smaller then their minimum size should overflow?
14:00:42 [dael]
fantasai: It should be a min-size.
14:00:46 [dael]
TabAtkins: Does that happen?
14:00:49 [Zakim]
Zakim has left #css
14:01:00 [leaverou]
leaverou has joined #css
14:01:09 [dael]
fantasai: We shouldn't be like the flex item is smaller then it actually is. If the table has a min-size it should be reflected in the min size in the algo.
14:01:30 [plinss]
plinss has joined #css
14:01:38 [dael]
TabAtkins: If it has a specified size to . Content of 200px but width of 10px. It'll be 200px but we don't go down a path to look at the contents.
14:02:08 [dael]
fantasai: THe table has a minimum size that's not reflected in min-size property. Max of specified min size and min size from table layout should be the size.
14:02:13 [dael]
TabAtkins: Yes, that makes sense.
14:02:18 [dael]
dbaron: And only for auto layout things?
14:02:20 [dael]
fantasai: Yes.
14:02:27 [dbaron]
14:02:40 [dael]
Rossen: If width is spec it's still a min-width
14:02:54 [dael]
rune_: Flex consideres and explicit width as a min-width?
14:03:11 [dael]
TabAtkins: At all times tables cannot shrink below their minimum content
14:03:25 [dael]
rune_: Can you put that in the spec somewhere?
14:03:29 [dael]
TabAtkins: Sure.
14:03:31 [cbiesinger]
14:03:39 [dael]
TabAtkins: Between flexbox and table spec we'll put this.
14:03:58 [dael]
fantasai: Used min-width of a table considers the content of the table and then we make sure flexbox hooks into that.
14:04:14 [dael]
astearns: We only want flex algo to key of used min-width for tables.
14:04:32 [dael]
fantasai: No reason for it not to in general. We just need to make sure correct terms are in flexbox and that tables has that concept.
14:04:38 [dael]
astearns: Used min-width isn't a term?
14:04:48 [dael]
fantasai: It is, but we need to make sure tables spec uses it.
14:04:55 [dael]
astearns: Used means layout has happened.
14:05:03 [dael]
TabAtkins: This is a flex item.
14:05:10 [dael]
rune_: You need min-width before you layout flex item.
14:05:17 [dael]
TabAtkins: Sure. Tables need to do layout earlier.
14:05:21 [cbiesinger]
14:05:30 [dael]
fantasai: Just calc min-content width.
14:05:43 [dael]
astearns: Prop: define what used min width is for tables and to make sure the flex algo uses that.
14:05:57 [dael]
astearns: That's the approach we're taking. Let's have you all come up with proposed edits.
14:06:12 [dael]
cbiesinger: Anything else have the used min-width?
14:06:28 [dael]
fantasai: No. Nothing else has a used min-width that depends on random other information.
14:06:31 [dael]
astearns: Anything more on this?
14:06:40 [dael]
Topic: Proposing Flexbox Level 2
14:07:19 [dael]
fantasai: TabAtkins and I suggested we draft L2 where it's flexbox 1 + the current set of alignment properties with all their values. Flexbox 1 only has a subset of alignment.
14:07:34 [dael]
fantasai: It's L1 + aligning keywords + gap properties so people can talk about it.
14:07:49 [dael]
TabAtkins: Technically you can read alignment and sizing and figure it out but this would be convenient.
14:08:18 [dael]
fantasai: We'd have to dup some parts of the algo but most we can say refer to current Flexbox. We're getting very stable so end of the year I think we can fold it in.
14:08:28 [dael]
astearns: Flexbox level 2 would mostly be a diff spec?
14:08:42 [dael]
TabAtkins: It shouldn't be a diff spec, just Flexbox 1 with some extra stuff.
14:09:15 [dael]
fantasai: Basically normative references into flexbox and alignment and some normative text on how it combines with maybe some quotes from the algo. Then in the future we'll fold in all the text.
14:09:22 [dael]
astearns: Sounds like it would be best as an ED
14:09:24 [dael]
TabAtkins: Yeah
14:09:34 [dael]
fantasai: Yeah. Once alignment goes to CR we should have a WD
14:09:36 [dael]
TabAtkins: Sure
14:09:46 [dael]
astearns: Objections to an initial ED of Flexbox L2?
14:09:57 [dael]
RESOLVED: have an initial ED of Flexbox L2
14:10:19 [dael]
Topic: Outstanding requests from TTML
14:11:14 [dael]
14:11:52 [dael]
fantasai: If you load the first link the first issue you'll get the PDF.
14:12:24 [dael]
fantasai: Basic issue is you have a paragraph or a sentence. You put it in a box with a width constraint so it wraps. All the lines of text aren't 100% filled. One is 80% one with 50% full.
14:12:41 [dael]
fantasai: You want text left aligned byt the paragraph to be centered in its container.
14:13:00 [dael]
fantasai: We can't do this in CSS. TTML would like for us to be able to do this. Different ways to approach it.
14:14:01 [dael]
TabAtkins: Line beak is between is and enormous in the example. They want text left aligned but once you have the line breaks center the group and then left align within the established center.
14:14:13 [dael]
astearns: Text can do this in a 2 line, they want this in a 3 line scenario
14:14:22 [dael]
TabAtkins: And any line might be the longest.
14:14:35 [dael]
Rossen: If we have padding auto, that's what they want.
14:14:45 [dael]
astearns: Not only centering
14:15:10 [dael]
dbaron: Underlying feature is you want to re-shrinkwrap the width of the block and then figure out what to do with it.
14:15:26 [dael]
florian: This is a sizing thing or a text effect thing.
14:15:53 [dael]
fantasai: If this was laid out with css the left gap would not be here.
14:16:01 [dael]
Rossen: You're sure we can't with flexbox?
14:16:11 [dbaron]
s/block/block after wrapping lines/
14:16:18 [dael]
TabAtkins: Yes. YOu need to re-shrinkwrap after linebreaking and flexbox determines size after linbreaking.
14:16:32 [dael]
myles: So you want to layout the first line, figure out the width?
14:16:46 [dael]
dbaron: Layout all the lines, figure out which is the longest, and then shrink
14:17:11 [dael]
dbaron: You have a size, layout all the line in the size, then change the width of the block smaller so that it's lined up with the widest.
14:17:17 [dael]
myles: Does flaots make that real harD?
14:17:21 [dael]
dbaron: Probably
14:17:45 [dael]
TabAtkins: Solution was a second level of text alignment where it's within the bounds of the longest line. Should be fine with floats, or at least well defined.
14:17:55 [dael]
dbaron: You'd have to do work to define what to do with extra bits.
14:18:07 [dael]
florian: Driving use case isn't floats driven.
14:18:14 [dael]
TabAtkins: And you don't need a second wrapper to get that.
14:18:28 [dael]
astearns: You and I TabAtkins have some solution just properties are reverced.
14:18:56 [dael]
dbaron: I think what I desc is what browsers did pre-CSS. Like netscape 4 would narrow the backgrounds to make the longest line.
14:19:56 [dael]
astearns: To my mind what's happening is here you have a center-left paragraph. We lay it out as if it's left aligned, taking the longest line and centering the whole paragraph. I'm looking similar to text-align-last, I suggested text-align-inner where you say this is acentered paragraph by inner is left.
14:20:02 [dael]
floI saw it the other way around.
14:20:10 [dael]
astearns: I forgot how TTML asked.
14:20:25 [dael]
florian: I htink TabAtkins is better for forward compat. left left is better then fully centered.
14:21:06 [dael]
TabAtkins: fantasai pointed out a futher use case when handling some CJK topography where most content-ful should be centered but shorter are justified by the width. Right now you have to size the box with ic unit.
14:21:24 [dael]
fantasai: That would solve a complain from CJK that jsutification causes their lines to have space.
14:21:38 [dael]
florian: I think there is still advanced CJK alignment, but this gets up most of what they want.
14:21:42 [fantasai]
s/space/too much space/
14:21:50 [dael]
myles: This is center-left and you're talking center-justified?
14:22:03 [dael]
astearns: this is a text-align: left with a tex-group-align: center
14:22:16 [dael]
fantasai: And when there's floats you try to shorten as much as the shortened line.
14:22:27 [fantasai]
s/shorten as/shift as/
14:22:32 [dael]
florian: For TTML float interuption is unimportant, but in CJK we care.
14:22:34 [fantasai]
s/line/line would allow/
14:22:42 [dael]
koji: So it's a group?
14:23:03 [dael]
fantasai: The question we have to think about is from TTML if we only deal with one block it's probably good enough.
14:23:07 [dael]
florian: Per BFC instead?
14:23:28 [dael]
TabAtkins: I was assuming 2 paragraphs there were use cases to have them the same. Don't cross BFC bounderies.
14:23:36 [dael]
myles: What happens if you put it on one paragraph of BFC>
14:23:53 [dael]
TabAtkins: It FCs the block or it's ignored because block is not a BFC.
14:23:59 [dael]
dbaron: Inherited or non?
14:24:00 [dael]
TabAtkins: Non
14:24:12 [dael]
myles: Put it on your BFC and hopefully authors knows what a BFC is
14:24:49 [dael]
fantasai: I don't think it needs to BFC anything. If we're going to have a block, a section with 2 paragraphs is we want them to be a unit they property has to be non-inherit and when you apply on a section it modifies line box on both sections.
14:24:52 [dael]
astearns: More complicated.
14:25:03 [dael]
florian: blocka nd to descendencts
14:25:23 [dael]
fantasai: You break at BFC bounderies. The block itself doesn't need to be a BFC
14:25:43 [dael]
dbaron: It applies to all the lines that are in this block and it's descendent blocks? Only traversing child blocks and not into the lines?
14:25:46 [dael]
fantasai: Right.
14:26:12 [dael]
dbaron: I feel like scope is similar to first-letter or text-indent for finding things? But those just look at first and this is looking at all?
14:26:32 [dbaron]
dbaron: ... never mind text-indent, that's inherited
14:26:32 [dael]
astearns: Before we go further into complicating we should ask the TTML people if they want to align paragraphs.
14:26:38 [dael]
florian: CJK does
14:26:53 [dael]
koji: CJK the whole block is one BFC and then we need to layout everything.
14:27:04 [dael]
florian: For CJK case i'm worried about floats.
14:27:11 [dael]
TabAtkins: [whiteboards floats]
14:27:24 [dael]
TabAtkins: Have big element and a floating picture and some text.
14:27:49 [dael]
TabAtkins: This block of lines having a shorter allowed line width is handled separately for the second block?
14:27:54 [dael]
Rossen: That would be horrible.
14:28:01 [dael]
fantasai: I don't think separate blocks.
14:28:16 [dael]
dbaron: Look at the exits, not the lengths.
14:28:29 [dael]
florian: floats are aligned to the box
14:28:35 [dael]
fantasai: no
14:28:53 [dael]
dbaron: So you have some excess on each line, figure out the smallest, and use that for the alignment.
14:29:01 [dael]
Rossen: But then add a float o nthe right side.
14:29:10 [dael]
dbaron: THere's still excess on each line.
14:29:33 [dael]
TabAtkins: Excess you know whichever has the smallest because all the others can be adjustested jsut as much.
14:30:03 [dael]
dbaron: Suppose you're crossing multiple blocks and they have different text alignment. You block align it center, and you have a child with right align.
14:30:53 [dael]
dbaron: You accumulate excess on both sides and use the smallest from both. I think that's similar. If the left aligns have 0 and the right is whatever is the smallest. If you're then told to center you move the over by that much.
14:31:28 [dael]
fantasai: I was thinking alignment after the group alignment. You find out the shortener and then you shrink your line box. Then we center in the remaining space after we apply group alignment.
14:31:31 [dael]
dbaron: I think you're right.
14:32:00 [dael]
florian: Use cases to make it more complex then TTML wants are CJK. If we're not solving moving the alignement we're not solving CJK.
14:32:11 [dael]
astearns: I suuget we design this only at the paragraph level.
14:32:26 [dael]
TabAtkins: Won't work if there's floats for CJK. We want the extra shrinkwrapping.
14:32:34 [dael]
[everyone talks]
14:32:48 [dael]
iank_: We want smartness and things will be complex.
14:33:00 [schuki]
schuki has joined #css
14:33:04 [dael]
fantasai: Offset on list is in respect to he edge of the lin with alignment so it'll move with this.
14:33:25 [dael]
astearns: Let's get the conversation to one person at a time.
14:33:48 [dael]
TabAtkins: I think this needs more design. I don't think we should agree right now, but it's good to get this in fron tof people.
14:33:55 [dbaron]
I think the CJK usecase requires the block-level thing that Netscape 4 did.
14:34:33 [dael]
fantasai: Before we consider restrict to single paragraph we should hear from TTML to see if it works for them. I think we have agood idea what we want to try and let's see if it works. I would suggest we draft the proposal into Text 4 and work it through as a part of writing.
14:34:39 [dael]
astearns: And having sep issues.
14:34:49 [dael]
florian: Most solve TTML, nice for CJK
14:35:10 [dael]
astearns: Add a text-group-align property to text 4 with an outline and open issues on that text once it's drafted.
14:35:13 [dael]
astearns: Obj?
14:35:22 [dael]
koji: Early someone mentioned creating an anon block?
14:35:30 [dael]
fantasai: I think that's more difficult for the mechanism.
14:35:47 [dael]
fantasai: Can you explain the use cases in the issue?
14:35:51 [dael]
koji: Yes.
14:36:02 [dael]
RESOLVED: Add a text-group-align property to text 4 with an outline and open issues on that text once it's drafted.
14:36:09 [dael]
astearns: And we'll talk witht he TTML.
14:36:13 [dael]
fantasai: They're looking to edit.
14:36:31 [dael]
Topic: Allow background of an inline area to extend to before-and after-edges of the line area
14:36:40 [dael]
14:37:32 [dael]
astearns: In this onethere is a PDF of what they'd like. There can be vertical gaps between lines that don't get a background color in CSS. They'd like to spec that hte background should be extended to be contiguous even if there's a gap like this.
14:37:42 [dael]
TabAtkins: I don't like the magical background
14:37:46 [dael]
fantasai: Should say it's the box.
14:37:56 [dael]
TabAtkins: Is this related to linebox size calc proposal?
14:38:10 [dael]
dbaron: Prob not. One questions is what to do if box is bigger then the line gap.
14:38:24 [dael]
florian: semi-transparent you don't want transparency to pile up.
14:38:37 [leaverou]
what about background-clip: line-box? :)
14:38:50 [dael]
tantek: For borders you can do the cheap and ugly overlapping borders or the likely wanted borders around the whole thing.
14:39:08 [dael]
astearns: My summary was insuficeient. It's also extending background on both sides to half the gap.
14:39:19 [dael]
florian: Consistent with increasing height of inline block.
14:39:27 [dael]
dbaron: What if there's a tall image on one line?
14:39:39 [dael]
astearns: I asked about what if a float is in the way and they didn't care.
14:40:07 [dael]
smfr: Feels a little like how when webkit does selection and tries to eliminate selection gaps?
14:40:51 [dael]
TabAtkins: In float example I suspect wouldn't be contiguous...first line is a little bigger but not touching. That's solved by inlines being the height of the line property.
14:40:57 [dael]
astearns: How to accomplish this.
14:41:11 [dael]
florian: inline height: auto and fill
14:41:30 [dael]
florian: inline property with legacy and filled.
14:41:36 [dael]
leaverou: line box as psuedo element?
14:41:43 [dael]
fantasai: Wouldn't solve the problem.
14:41:49 [dael]
leaverou: Wouldn't line height address it?
14:42:09 [dael]
TabAtkins: Inline box sizing wrap the content reasonably tight such that line height can produce gaps.
14:42:35 [dael]
leaverou: If there's a linebox psuedo element wouldn't they be able to set padding?
14:42:49 [dael]
florian: pseudo element controls too many things.
14:43:06 [dael]
fantasai: Can we pause this and switch to next issue? It's similar in the opposite axis.
14:43:18 [fantasai]
Topic: line-start/end padding
14:43:22 [fantasai]
14:43:31 [fantasai]
leaverou, they're the first links in each issue
14:44:03 [dael]
fantasai: This one is an issue where they want padding at start and end of line and applied to inner most element at that point.
14:44:55 [dael]
fantasai: If ou have a span broken across 2 lines and at the end line padding is inserted into the span. With CSS you can wrap all the text but it gives you the last result. THis is effectively the opposite of letter spacing. This is outside the letter on the start and end.
14:45:16 [dael]
fantasai: SHould be easy to impl, but we need syntax for it. I wanted to do this because it's easy to understand.
14:45:33 [dael]
TabAtkins: Am I imagining a difference in the black line from hello and my?
14:45:38 [dael]
fantasai: I think that's not intentional.
14:45:44 [dael]
TabAtkins: Okay.
14:45:55 [dael]
myles: If you have 2 nested do you use innermost
14:46:07 [dael]
TabAtkins: It would be like letter spacing where one wins on the letter that ends the line.
14:46:11 [dael]
florian: this inherits?
14:46:16 [dael]
fantasai: I think that's simple.
14:46:28 [dael]
TabAtkins: Has to. Letter spacing but for the space where we don't put letters.
14:46:52 [dael]
myles: Recommendation is at the tie you do the line breaking you do this for the end of the line? Not sure how it works for beginning.
14:47:16 [dael]
fantasai: You look at first character on your line and before you figure out how big the character is and like that you have to go forward a bit.
14:47:46 [fantasai]
You take the line-padding value of that character
14:47:50 [dael]
astearns: They use line padding as the avenue to control this.
14:48:04 [dael]
fantasai: We could introduce a line-padding property that has a longhand.
14:48:13 [dael]
florian: and if you're intrupted by a float?
14:48:18 [dael]
fantasai: It's between you and the float.
14:48:25 [dael]
dbaron: Are there interesting things with bidi?
14:48:27 [dael]
fantasai: no.
14:48:32 [dael]
dbaron: pre or post reordering
14:48:33 [dael]
fantasai: post
14:48:50 [dael]
myles: there's always a character at the end of the line. Whatever element that's part of is what you consult.
14:49:02 [dael]
florian: If you're post-reorder you might get a different character at the end.
14:49:16 [dael]
fantasai: Alternative is have this on the block. Whatever block makes the line box gets the value
14:49:24 [dael]
Rossen: Similar to the box direction.
14:49:30 [dael]
TabAtkins: Then you jsut shoot the line box.
14:49:42 [dael]
TabAtkins: Possiblity is make it not inherit.
14:49:56 [TabAtkins]
14:49:59 [dael]
fantasai: YOu want inherit because you mana anon boxes. BUt you can put it on the block container at which point it's applied.
14:50:07 [TabAtkins]
14:50:19 [dael]
florian: I think possibility of different padding based on bidi is not useful and complicates things quite a bit.
14:50:41 [dael]
TabAtkins: This does seem better. NO drilling down and no bidi. I like this.
14:51:13 [pal]
pal has joined #css
14:51:19 [dael]
fantasai: The property is inherited by applies to block containers. When you do your layout you look at line padding property of the line box you're in which comes from the block container.
14:51:37 [dael]
fantasai: I guess we're rsolved on that approach of having the property
14:51:42 [dael]
astearns: Text level 4 again?
14:51:56 [dael]
fantasai: Yeah. Other option is css Inline. Not sure where it fits better.
14:52:21 [dael]
astearns: Prop: Add a line-padding property as described in minutes to text level 4.
14:52:28 [dael]
RESOLVED: Add a line-padding property as described in minutes to text level 4.
14:52:40 [dael]
Topic: Allow background of an inline area to extend to before-and after-edges of the line area
14:52:49 [dael]
14:53:18 [dael]
fantasai: In this case I think we need to apply to the inline.
14:53:31 [dael]
florian: I don't know if you need to but there's no complication on it.
14:53:35 [fremy]
14:53:40 [dael]
koji: When talking about extending inline boxes height?
14:53:42 [fremy]
14:53:45 [dael]
fantasai: Only for painting.
14:53:47 [dael]
Rossen: Is it?
14:54:03 [dael]
fantasai: Yes, layout is based on line height. We don't care about padding, amrgins etc.
14:54:10 [florian]
florian has joined #css
14:54:12 [dael]
fremy: I put a link on IRC that's a website that tries to do this.
14:54:31 [dael]
fremy: I think how the did it is set some padding on the line and let's you extend the background.
14:54:38 [dael]
Rossen: They'll have overlap.
14:54:47 [dael]
dbaron: If you choose too much you cover up text in other line.
14:55:00 [dael]
Rossen: If you resize the window down to 3 lines you lose some of the y
14:55:11 [leaverou]
fremy: I've also seen it done with box-shadow to simulate line-padding, it's a very common effect
14:55:19 [dael]
fremy: They also used box shadow.
14:55:40 [dael]
florian: Are we discussing a protential property that siwtches the outer content height of inline boxes to be the height of the line?
14:55:43 [dael]
dbaron: I think border height
14:55:47 [dael]
fantasai: Outer is margin
14:55:52 [dael]
florian: meant border.
14:56:31 [dael]
fantasai: Interesting thing is this is all element. What if I have superscript? I think what they would want is ou're still going from top to bottom of linebox. Amount of extra background ink [whiteboards]
14:57:13 [dael]
fantasai: If we draw this and want to increase by x on each side, but if you have an element with different baseline you'll want to go from top to bottom of linebox. Normally when calc size of background area you're going to use the size of the contents, your font metrics.
14:57:35 [dael]
fantasai: We're saying isntead of doing that ignore where all the text is, just find the lin box and draw from the top to the bottom.
14:57:51 [dael]
fantasai: Should be clear regardless of the vertical positioning the background moves with the txt.
14:58:08 [dael]
fantasai: Might be margin box you want.
14:58:19 [dael]
dbaron: NO harm in the margin box because then it makes margin useful.
14:58:28 [dael]
dbaron: Then you could inset some of the background.
14:58:42 [dael]
florian: It's commonly set i nboth direction because it only does something in one.
14:58:48 [dael]
TabAtkins: This won't be turned on by default.
14:58:51 [dael]
florian: I guess.
14:59:06 [dael]
dbaron: Also let's people make the border stick out by using a negative margin.
14:59:09 [dael]
florian: Okay. I buy that.
14:59:27 [dael]
florian: Property with normal and fill?
14:59:49 [dael]
fantasai: Or add it as a keyword on padding property. Padding top-fill so it means make the padding such...
14:59:56 [dael]
astearns: Then you have to do it on each direction
15:00:01 [dael]
fantasai: We have padding-block-start.
15:00:21 [dbaron]
I'd note that this does introduce negative padding, which might be interesting...
15:00:45 [fantasai]
fantasai: You could say 'padding-block: fill'
15:00:48 [fantasai]
on the inline
15:00:52 [dael]
Rossen: I would the prefer this to be inline background. We can figure out what the bounds are. We don't have to implode padding or margin. It's a drawing effect. That way once we switch we can ensure there's no overlapping so when you're using semi-transparent it's always complete.
15:01:18 [dael]
Rossen: If it's only after rendering I would prefer higher lelev. Pushing this down to lineline you'll have some times do it and it's more complex.
15:01:33 [dael]
fantasai: Wht makes it more complex to impl? On every inline you haev to call the paint your backgrounds function.
15:01:43 [dael]
iank_: This goes over the size of the line potentially.
15:01:48 [dael]
fantasai: You have to handle that for line-height.
15:01:53 [dael]
iank_: That's line-box sixe.
15:02:15 [dael]
fantasai: If I set my line ehight ot 10 and padding on my inline box is 10 above and below I'll leak over.
15:02:50 [dael]
florian: Rossen you're version if the middle is top green and bottom yellow how to you know it doesn't overlap.
15:03:04 [dael]
Rossen: It doesn't. It's a simplification because it's one background behind all.
15:03:13 [dael]
Rossen: But they want different colors. Not jsut one element.
15:03:27 [dael]
15:04:02 [dael]
koji: smfr pointed out we do that code for selection painting. The approach is like what Rossen suggested, it's easy to impl. If we go with padding it's more complex.
15:04:15 [dael]
fantasai: padding doesn't effect [missed]. it changes box size but not things around.
15:04:26 [dael]
Rossen: You can have tearing or overlapping.
15:04:42 [dael]
fantasai: You can already do the overlapping. i'm not sure how concerns about overlapping or not are valid.
15:05:19 [dael]
florian: When you do approauch where you'r line height wasn't 20 pixels it's possible you migth get a bit of a gap inbetween. Instead of sizing each individually you can edit as one shape.
15:05:27 [dael]
fantasai: But then what about when you do images?
15:06:11 [dael]
myles: Our selection does it piecemeal. We're very deliberate about how we round and floor. It fills peices 1 by 1 and avoid pixel crack with careful rounding.
15:06:22 [dael]
Rossen: If we leave to authors we'll have different rounding.
15:06:51 [dael]
astearns: We're saying design the feature at an inline level and impl deal with stiching together with the rounding errors. And it's what TTML is asking for in the issue.
15:07:18 [dael]
astearns: Do we follow TTML lead and call it fill-linegap?
15:07:22 [dael]
fantasai: No.
15:07:30 [dael]
florian: inline-box-sizing?
15:07:39 [dael]
koji: Sizing is not right.
15:07:49 [dael]
florian: inline-height: normal|fill
15:07:56 [dael]
leaverou: Too much like line-height.
15:08:04 [koji]
s/is not right/sounds like layout/
15:08:17 [dael]
astearns: Line-extend
15:08:23 [dael]
iank_: border-outsets
15:08:30 [leaverou]
15:08:43 [dael]
fantasai: You're not outsetting, you could be insetting.
15:08:57 [dael]
florian: inline-height and line-height are similar but if you're aware of both you won't be confused.
15:09:06 [dael]
iank_: Not all webdev know all css properties.
15:09:14 [dael]
fantasai: line-gap-fill
15:09:29 [dael]
astearns: Pierre suggests line-box-fill on IRC
15:10:01 [dael]
[quiet contemplation]
15:10:39 [dael]
fantasai: thinking about to where we might extend there's a variety of metrics you might be interested in. Right now it's not entirely defined where the content box of the inline element is. You could want it to match em box, glyph bounding box.
15:11:12 [dael]
fantasai: Or match the edge of the line-box. There's several different values we might want at some point. You have a zapfino heading and you want a highlight behind.
15:11:17 [dael]
astearns: line-gap-fill-ink
15:11:50 [dael]
florian: if padding is applied to the outer padding goes in from there. Or we apply box-sizing.
15:12:12 [dael]
fantasai: Let's name the property. Fill value picks a value such that it fills the margin box.
15:12:25 [dael]
fantasai: We need a name and it should be compat with having different values in the future.
15:12:45 [dael]
fantasai: inline-sizing.
15:12:52 [dael]
florian: inline-height sounds fine to me.
15:12:59 [dael]
astearns: All the names inples changing geometry
15:13:16 [dael]
fantasai: We do change the geometry of the box. If you put a border the size of the border changes.
15:13:26 [dael]
astearns: [reads pal question]
15:13:41 [dael]
dbaron: replaces the padding I think. It's adjusting the paddign to make margin edge line up.
15:13:49 [dael]
dbaron: Also introduces possiblity of negative padding.
15:14:01 [dael]
florian: Do we only grow or also shrink is a separate question.
15:14:08 [dael]
fantasai: leaverou suggests
15:14:30 [dael]
leaverou: We can reuse line paddign and have it take 1-4 values for all directions and have a fill keyword.
15:14:55 [dael]
fantasai: I think....we had a fill keyword with 1-4 values what if you apply it to the inline-start.
15:14:59 [dael]
leaverou: I'm not sure.
15:15:27 [dael]
fantasai: If you have line-padding-inline-end: fill on a short line the color goes all the way to the edge. THat's not unreasonable.
15:15:39 [dael]
myles: And that's on a span so it's only to the end of the span if there's a linebreak?
15:15:45 [dael]
fantasai: Only if it's the end of the line.
15:16:03 [dael]
astearns: If it's in the middle it goes to the end of the span. If the span ended a line it goes to the end of the line box.
15:16:10 [dael]
myles: Line break in the middle?
15:16:32 [dael]
fantasai: If the span is in the middle and there's text at the end there's no effect. If the span breaks or is last thing the background goes to the end.
15:16:40 [dael]
myles: You have to look at deepest span?
15:17:13 [dael]
fantasai: In fill case...yeah. Yeah. You'd impl as adding extra space and all the spans extend to the end of the line. Wont' effect position, it's jsut poiint.
15:17:34 [dael]
florian: Confusing if there's whitespace with a different span at the end?
15:17:42 [dael]
fantasai: If you use whitespace-pre that's your fault.
15:18:13 [dael]
astearns: I think we have vague consensus on an approach. Is this in Inline? Would be nice for all TTML in one spec. Others are in Text L4. But this is more inline then text.
15:18:36 [dael]
astearns: Prop: Have a line padding shotrhand with all the attendant longhands that in additon to lengths takes a fill keyword.
15:18:54 [dael]
leaverou: Can we have a background:clip keyword that makes it so they don't have to wrap it in a span?
15:19:00 [dael]
fantasai: What element has the background?
15:19:17 [dael]
leaverou: Heading and you want to apply the linbox to the heading but you don't want to wrap the heading in a span.
15:19:32 [dael]
fantasai: You want a pseudo element for the root inline.
15:19:42 [dael]
leaverou: A new pseudo is more complex to add.
15:19:47 [dael]
fantasai: This is for a box that exists.
15:19:59 [dael]
leaverou: Why can't we use padding on that rather then a line wrapping property?
15:20:07 [dael]
fantasai: Padding is applied to inner most, not outer.
15:20:22 [dael]
florian: I thought we had normal and fill and you said lengths and fill.
15:20:32 [dael]
fantasai: This use case for inline needs lengths.
15:20:41 [dael]
florian: They apply to different things.
15:20:53 [dael]
myles: Instead oa new property why wouldn't you use lineheight to move lines?
15:21:08 [dael]
fantasai: Not changing layout which is what line height does. We're changing how box is painted.
15:21:13 [dael]
myles: what does length do?
15:22:10 [dael]
fantasai: We discussed adding space like letter spacing, that needs length. Then we discussed how to fill disance between edge of box and edge of linebox and that takes keywords. leaverou asked why not have a single set of 4 properties that solves both use case.. But we're not ure we can.
15:22:37 [dael]
florian: One was desc as working on block and the other on inlines. fill could be made to work in both, but let's not. It looks like 2 sets of 2 things
15:22:51 [dael]
astearns: Prop: A line-padding property?
15:23:08 [dael]
myles: It's valuable to not conflaint properties that mess with layout and ones that mess with paint
15:23:26 [dael]
fantasai: line-padding was for the letter spacing type thing. I think line-padding is a fine name.
15:23:36 [dael]
fantasai: We need a name for the one in the other axis.
15:23:59 [dael]
fantasai: That's changing how we size the box for painting purposes. We've got normal which is what we do not and fill the line box.
15:24:05 [dael]
myles: CHange veritical alignment?
15:24:08 [dael]
fantasai: It does not.
15:24:23 [dael]
florian: We might in the future want to separate extending top and bottom side.
15:24:41 [dael]
fantasai: I think we'll start with one value for both of these. If someone wants different we can split.
15:24:57 [dael]
myles: Background will paint outside of the boxes the spans create?
15:25:03 [dael]
florian: You're extending that.
15:25:19 [dael]
fantasai: That box has no effect on layout in vertical. It's only about painting.
15:25:38 [dael]
fantasai: It doesn't change where the text is for that or any element.
15:25:45 [dael]
florian: And you can already set hte border.
15:26:00 [dael]
leaverou: We're trying to come up with a second property name for the fill keyword, why not work in one direction?
15:26:27 [dael]
astearns: I think we're at the point where we can't combine the effects because where we're adding them in the inline is only block container and fixing the gaps can't.
15:26:35 [dael]
fantasai: One takes lengths and the other keywords.
15:26:51 [dael]
florian: And we are only missing a good name.
15:27:26 [dael]
astearns: Prop: A propserty to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.
15:27:40 [astearns]
15:27:49 [fantasai]
and might take additional keywords in the future
15:27:50 [dael]
florian: Remaining question for that property is if you have enough borders it would shrink into the text and then what?
15:28:11 [dael]
florian: If you have 20px height and 30px borders, did you ask for that and that's your problem?
15:28:20 [dael]
dbaron: Related to the can it go negative question.
15:28:33 [dael]
fantasai: Overflow doesn't apply for inline. Border goes behind the text.
15:28:54 [dael]
fantasai: Which is reasonable in a lot of cases. The alyout area you might want to have negative padding to get things to look the way you want.
15:28:58 [dael]
florian: Okay.
15:29:09 [dael]
florian: Do we need to define borders are behind the text or is that clear?
15:29:14 [fantasai]
The glyph area of a character might be significantly smaller than the em box
15:29:17 [dael]
astearns: I think next step is get this in the draft.
15:29:23 [dael]
astearns: Obj to having this property?
15:29:42 [dael]
RESOLVED: Add a property to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.
15:29:56 [dael]
astearns: Added to CSS Inline. Ideas on names are welcome.
15:30:19 [dael]
Topic: end
15:31:04 [dael]
[schedule wrangling]
15:31:17 [dael]
Topic: overflow:clip
15:31:23 [florian]
15:31:27 [florian]
15:32:00 [dael]
florian: Missed the telecon where we discussed. We recently resolved overflow:clip does not trigger BFC. I think it failed to considered some of the things that implies.
15:32:57 [dael]
florian: The motivation that triggered adding to spec was usage in combo with contain:paint so you can have contain:paint with text overflow or resize property. Only apply to overflow not visible elements. We don't want to use contain:paint with overflow:hidden because UA might look for too many resources.
15:33:22 [dael]
florian: If overflow:clip does not creat a BFC are impl comfrotable saying resize and text overflow applies to elements that are overflow:clip?
15:33:55 [dael]
TabAtkins: During discussion before we couldn't come up with you'd want overflow without scrolling, this is the reason. There are properties that depend on things being non-visible.
15:33:58 [dael]
florian: Resize.
15:34:10 [dael]
fantasai: I think it doesn't matter for resize.
15:34:33 [dael]
florian: I'm not saying should not apply. but if we're going with it's not a BFC we also have a bunch of properties that should change to not visible or clip.
15:34:39 [dael]
dbaron: There were use caes for the opposite.
15:34:40 [fantasai]
and I think that 'text-overflow' should never have keyed off of 'overflow'
15:35:06 [dael]
TabAtkins: This is the use case for this situation. WE only can up with use cases for the other resolution. Something tha tacts like overflow:visible but it's clipped.
15:35:07 [AmeliaBR]
AmeliaBR has joined #css
15:35:13 [dael]
florian: NOt effect margin collapsing.
15:35:22 [dael]
TabAtkins: Or sticky or scrollsnap.
15:35:34 [dael]
TabAtkins: This is a reason for the opposite where it's like hidden but don't scroll.
15:35:54 [dael]
dbaron: They can't apply for text:overflow partly because this is a purely paint time effect.
15:36:09 [dael]
florian: This is also a purely paint time.
15:36:11 [dael]
fantasai: True.
15:36:58 [dael]
dbaron: I guess those two could maybe be changed to not include the visible. Nothing is like this because we've put overflow does not equal visible across all our specs where that's not what we mean.
15:37:13 [dael]
fantasai: I think a lot that key off overflow not visible key off if it's a BFC.
15:37:43 [dael]
fantasai: I think a lot of things are keying off that. There's many effects that key off of that and we don't have to handle the spec. There may be sone that don't.
15:38:07 [dael]
florian: That we need to rename was mentioned. If we clarify that doesn't apply to text-overflow and resize that solve my first concern.
15:38:19 [dael]
florian: Are we okay closing that sub topic?
15:38:24 [dael]
astearns: Additional concerns?
15:39:24 [dael]
florian: Assuming we don't find another problem we can clarify the previous resolution to mean text-overflow and resize refer to non-visible elements.
15:39:57 [fantasai]
fantasai: To rephrase Florian without negatives, text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
15:40:23 [dael]
florian: The second concern was about what overflow:clip means when applied to the document or body element and propegate to viewport
15:40:40 [dael]
fantasai: Same way we transpate visible to auto we translate clip to auto.
15:40:44 [dael]
florian: That's good.
15:40:47 [innovati]
innovati has joined #css
15:40:59 [dael]
15:41:07 [dael]
astearns: Resolve on both?
15:41:23 [dael]
astearns: Prop: text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
15:41:27 [dael]
RESOLVED: text-overflow and resize apply to elements with 'overflow: clip' just as they apply to elements with 'overflow: hidden'
15:42:00 [dael]
astearns: Prop 2: when overflow:clip is propagated to the viewport it's changes to overflow:hiddent he same way visible is changed to auto
15:42:13 [dael]
RESOLVED: when overflow:clip is propagated to the viewport it's changes to overflow:hidden the same way visible is changed to auto
15:42:31 [dael]
astearns: You're fine with the resolution?
15:42:42 [dael]
florian: Yes. I'm mildly skeptical, but not objecting.
15:42:44 [dael]
Topic: end
15:42:56 [dael]
opic: padding-bottom in overflow content
15:43:00 [dael]
Topic: padding-bottom in overflow content
15:43:09 [dael]
15:44:12 [dael]
github: none
15:44:27 [fantasai]
Topic: logical longhands for overflow
15:44:29 [fantasai]
15:44:31 [dael]
Topic: Add overscroll-behavior-[block/inline] in accordance with css-logical
15:44:36 [dael]
15:45:12 [dael]
majidvp: There's a resolution to add this to oerflow inline and block which is reasonable.
15:45:31 [dael]
florian: We don't have a resolution on this. We have it on similar.
15:45:46 [dael]
astearns: Overflow vs Overscroll. Oooh.
15:45:53 [dael]
astearns: Obejctiosn to adding block and inline to overscroll behavior?
15:46:02 [dael]
RESOLVED: add block and inline to overscroll behavior
15:46:15 [dael]
Topic: Let 'overflow' accept two values
15:46:22 [fantasai]
15:46:22 [dael]
15:47:41 [dael]
Oriel: It only lets you set overflow-x and overflow-y. It would be more convenient if it accepted two values. Then there was the question is the order should be physical or logical. As an example background-position is x and y. It will prserve physical order. There's another issue looking to switch longhand and shorthand into phsycial order.
15:47:58 [dael]
florian: Other is issue #1282 which discussed adding logical keyword to all places currently phsycial.
15:48:12 [dael]
astearns: Separate from that switch, do we let overflow accept 2 values?
15:48:23 [dael]
astearns: Concern about changing this?
15:48:36 [dael]
astearns: Weird mistyped decalrations may now have an effect?
15:48:50 [dael]
florian: I suggest we presume that's rare and if it's a problem we raise it
15:49:05 [dael]
florian: A more consistant system where they all have shorthands and they're physical.
15:49:22 [dael]
astearns: Prop: Allow overflow to have two value and for the ordering to be physical.
15:49:30 [dael]
iank_: Which order?
15:49:34 [dael]
emilio: x and y.
15:50:15 [dael]
dbaron: Quesiton: There are sets of values transofrmed into other values. If x is visible and y is scroll we make scroll into auto. Should those combos be syntatically valid for shorthand?
15:50:26 [dael]
myles: Related that this shorthand shouldn't allow new functionality
15:51:01 [dael]
dbaron: Transofrmation would still happen. I'm thinking a it would be nice if it rejected but b it's not possible because serialization problem. Because then values could not serialize to short hand
15:51:06 [dael]
emilio: Happens in a lot of places.
15:51:29 [dael]
dbaron: I guess it's not really a serialization problem. Do we want the things that are not going to be valid in the end be parse errors?
15:51:45 [dael]
emilio: I think it would be weird if spec shorthand would yield different results.
15:51:58 [dael]
myles: You set the shorthand and it's rejected and that's different that if you set the 2 longhands.
15:52:15 [dael]
florian: You have a minifier and it takes the 2 longs and puts them to short and that's a parse error.
15:52:34 [dael]
astearns: I would prefer let ou set the shorthand to whatever and letting it transform.
15:52:45 [dael]
florian: I don't think we gain by forbidding these.
15:52:54 [dael]
fantasai: If you serialize out computed values it's valid.
15:53:06 [dael]
florian: What do we gain by forbidding?
15:53:15 [dael]
dbaron: Reject things that don't makes sense.
15:53:31 [dael]
florian: Makes sense when you transform.
15:53:40 [dael]
dbaron: CSS ties to reject things that don't make sense.
15:53:49 [dael]
fantasai: Would be nice if a validation pool flagged this.
15:53:49 [dbaron]
15:53:54 [dbaron]
15:53:55 [dael]
astearns: Computed value shows something changed.
15:53:59 [dael]
fantasai: That always happens.
15:54:16 [dael]
emilio: [missed] fantasai Tranforming em to pixel doesn't show you've got a problem in your style sheet.
15:54:35 [dael]
astearns: I'm not certain having a transofmr apply implies there's a problem in your stylesheet.
15:54:41 [dael]
fantasai: rachelandrew?
15:54:46 [dael]
rachelandrew: I don't have an opinion.
15:55:02 [dael]
florian: Stylesheet maintenece it's strange.
15:55:09 [dael]
myles: Have we never encountered this?
15:55:28 [dael]
fantasai: Almost for display but we made all combos invalid. We got rid of the longhand.
15:55:47 [dael]
emilio: Outline style stuff which when you have hidden outline and the line-width becomes 0.
15:56:14 [dael]
astearns: Anyone have a concern with allowing whatever combo we spec? Anyone object to taking what we get and stransform?
15:56:35 [dael]
astearns: Prop: Allow 2 values on the overflow property in physical x/y order in any existing values.
15:56:48 [dael]
myles: What a combo authors want with different keywords?
15:56:56 [dael]
astearns: hidden x auto in y.
15:57:01 [dael]
myles: So only one scroller.
15:57:35 [dael]
astearns: People use overflow x and y in various situations and it' sjust that it would be nice to let them use the shorthand for both.
15:57:51 [dael]
rune_: If you have visible overflow in x and y you get visible.
15:57:57 [dael]
florian: Transformed to auto.
15:58:07 [dael]
myles: Hiddena nd auto are okay.
15:58:09 [dael]
astearns: Obj
15:58:13 [dael]
RESOLVED: Allow 2 values on the overflow property in physical x/y order in any existing values.
15:58:16 [dael]
topic: end
15:58:22 [dael]
astearns: we're done for the day.
15:58:45 [astearns]
trackbot, end meeting
15:58:45 [trackbot]
Zakim, list attendees
15:58:53 [trackbot]
RRSAgent, please draft minutes
15:58:53 [RRSAgent]
I have made the request to generate trackbot
15:58:54 [trackbot]
RRSAgent, bye
15:58:54 [RRSAgent]
I see no action items