15:54:53 RRSAgent has joined #css 15:54:53 logging to http://www.w3.org/2017/07/19-css-irc 15:54:55 RRSAgent, make logs public 15:54:55 Zakim has joined #css 15:54:57 Zakim, this will be Style_CSS FP 15:54:57 ok, trackbot 15:54:58 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:54:58 Date: 19 July 2017 15:55:10 bdc has joined #css 15:55:58 CSSWG_LogBot has joined #css 15:56:17 present+ 15:56:27 present+ 15:56:33 ScribeNick: dael 15:58:42 present+ 15:59:39 antonp has joined #css 15:59:51 present+ 16:00:29 alex_antennahouse has joined #css 16:00:36 present+ 16:00:42 bdc has joined #css 16:00:45 present+ dauwhe 16:00:46 present+ antonp 16:00:56 present+ bdc 16:01:03 Rossen_ has joined #css 16:01:07 present+ 16:01:18 Present+ 16:01:34 MaRakow has joined #CSS 16:01:45 astearns: We'll give people a few more minutes to call in. 16:01:59 present+ 16:02:01 on flaky hotel wifi if I'm vanishing and reappearing 16:02:04 present+ 16:02:15 bcampbell has joined #css 16:02:38 present+ 16:03:00 present+ 16:03:44 astearns: 1 more minute 16:04:07 ChrisL has joined #css 16:04:49 astearns: We have a meeting in less than 2 weeks. 16:05:03 present+ 16:05:12 astearns: If you have not yet added your details tot he wiki please do. And add items to the agenda so we can get a possible schedule in mind. 16:05:21 https://wiki.csswg.org/planning/paris-2017 16:05:29 frremy has joined #css 16:05:41 astearns: Next, anything people want to add to the agenda? 16:05:46 present+ 16:05:52 Topic: Spec Rec next steps 16:06:03 astearns: Anyone have an update to share? 16:06:03 I just sent email seconds ago 16:06:24 bradk has joined #css 16:06:24 astearns: ChrisL sent an email seconds ago. There are updates for Fonts. Thanks. 16:06:28 astearns: Is fantasai on yet? 16:06:46 present+ 16:06:57 present+ 16:07:09 fantasai: I didn't do anything other than dealing with writing modes where I sent an update. There was a normative change, I pushed the change complied DoC, sent to ChrisL 16:07:14 astearns: So things are with ChrisL? 16:07:26 fantasai: ChrisL needs to figure out what's next to get published. I don't know what to do. 16:07:26 https://lists.w3.org/Archives/Public/www-style/2017Jul/0012.html 16:08:02 ChrisL: We were waiting on if we want to go to CR or PR. Seemed from the changes they were non-substantive, but fantasai thought it should be CR. I asked why. 16:08:20 https://github.com/w3c/csswg-drafts/issues/1591 16:08:29 fantasai: There's a message linked in IRC. THere's issue 1391. It's a substantive change, but quite minor. But I don't know what hte state of the process is. 16:08:29 do test cases reflect the normative changes? 16:08:39 is it a breaking change? 16:08:45 fantasai: I'd recommend a chat with Ralph to explain the changes. I thin it's silly to CR first. 16:08:50 ChrisL: That's listed in changes list? 16:08:53 fantasai: Yes, and DoC. 16:08:55 sorry, the link is https://github.com/w3c/csswg-drafts/issues/1391 16:09:01 ChrisL: Great. I'll take that to Ralph. 16:09:04 ChrisL: Thank you. 16:09:14 q+ 16:09:17 astearns: Anything else on the set of specs we're trying to get updated to CR? 16:09:25 fantasai: There's the list on the agenda for updating. 16:09:28 astearns: True. 16:09:46 tantek, https://github.com/w3c/csswg-drafts/issues/1391 16:09:48 Rossen_: I believe there are tests stuck somewhere for review, maybe Flexbox or Grid. Might be good to have eyeballs on those. 16:09:53 astearns: Are there people assigned? 16:09:57 Rossen_: I don't believe so. 16:10:04 Rossen_: Anyone can review tests. 16:10:25 astearns: Let's look this week at what tests are waiting review and you and I can assign someone to review to get things moving. 16:10:27 Rossen_: Sounds good. 16:10:28 notes that https://github.com/w3c/csswg-drafts/issues/1391 has a test case and has changes to reflect implementation interop / consensus. 16:10:35 q? 16:10:35 Topic: Publishing an updated WD of css-align and css-display 16:10:49 tantek: Quick note on writing modes. 16:11:14 +1 to tantek 16:11:15 present+ 16:11:17 tantek: I reviewed the issue and in my opinion I think we should go directly to PR. There is a test case and it's a change to reflect interop impl so it's not breaking. 16:11:26 thanks, t 16:11:29 tantek: I just wanted to add weight to the PR request. 16:11:32 sure 16:11:48 Rossen_: Should we get a resolution ChrisL? If it's going to be wortht he argument let's just cfc and move on 16:12:08 +1 16:12:09 astearns: proposal: request updated PR for writing modes instead of going back to CR b/c this change doesn't warrent going back to CR. 16:12:13 astearns: Obj? 16:12:14 because this particular change reflects reality (impl interop) 16:12:22 +1 16:12:28 yay! 16:12:32 RESOLVED: request updated PR for writing modes. 16:12:37 q? 16:12:38 t- 16:12:39 q- 16:12:43 s/t-// 16:12:50 Topic: Publishing an updated WD of css-align and css-display 16:12:51 t- ?? wow :) 16:12:56 astearns: align it's an updated WD 16:13:17 fantasai: Yep. We wanted dbaron approval on that since a lot of the issues were filed by him. If he's okay publishing now or wants more time to look. 16:13:44 dbaron: I think there's more work to do, but I wouldn't obj to a new WD. I went through the commentor response required, well, all but 3. THere were 4 I marked as not satisfied. 16:13:54 fantasai: Great. publish an update and keep working 16:13:55 that is an auto-publish, right? 16:14:02 astearns: Obj to updated WD of css align? 16:14:04 ChrisL, yes 16:14:12 RESOLVED: Publish an updated WD of css-align 16:14:30 astearns: Second is also updated WD of css-display. Looked like fewer issues. 16:14:50 fantasai: Fewer, but quite a few. We could do 1495 quickly before publish. We should do an update and then keep working. 16:14:50 https://github.com/w3c/csswg-drafts/issues/1495 16:14:59 github: https://github.com/w3c/csswg-drafts/issues/1495 16:15:02 GitHub: https://github.com/w3c/csswg-drafts/issues/1495 16:15:03 topic: https://github.com/w3c/csswg-drafts/issues/1495 16:15:29 fantasai: Suggestion was it's a little different then some of the others and do we really need this one. It might be worth dropping that unless someone has impl and wants to keep it. 16:15:49 astearns: Anyone know if inline-list-item has been imp? 16:15:58 Rossen_: I don't believe we are. 16:16:12 astearns: Obj to dropping inline-list-item? 16:16:22 No hits in Mozilla's codebase 16:16:26 RESOLVED: Drop inline-list-item 16:16:41 astearns: Obj to new WD of css-display? 16:16:50 RESOLVED: Publish new WD of css-display 16:17:03 Topic: Clarify passing by requirement of scroll-snap-stop for different category of scrolling 16:17:11 github: https://github.com/w3c/csswg-drafts/issues/1552 16:17:41 myles has joined #css 16:17:48 fantasai: We made some changes to clarify scroll snap stop in respect to different types of scrolling. New definition: 16:17:51 When scrolling with an intended direction, the scroll container can “pass over” several possible snap positions (that would be valid to snap to, if the scrolling operation used the same direction but a lesser distance) before reaching the natural endpoint of the scroll operation and selecting its final scroll position. The scroll-snap-stop property allows such a possible snap position to “trap” the scrolling operation, forcing the scroll container [CUT] 16:17:53 present+ myles 16:17:58 Values are defined as follows [...] 16:18:01 This property has no effect on scrolling operations with only an intended end position, as they do not conceptually “pass over” any snap positions. 16:18:29 Sorry, finally here. 16:18:39 fantasai: What we decided was it has no effect on a scroll that has an end point but no direction. That includes scrolls where you jump to an element or if you are driving or panning and let go at that point as you're dragging. 16:19:04 fantasai: Things with a direction like down arrow and page down and momentum scroll are tracked by scroll-snap stop 16:19:22 astearns: And I see one comment liking to wording. 16:19:36 fantasai: MaRakow looked it over and sent some comments. We replied. That was offline. 16:20:07 MaRakow: It seems generally fine. Main thing interesting is the previous lang talked about container, it seemed, though it was in the seciton about elements. I'm generally fine with the defintion unless [missed] 16:20:22 astearns: Anyone else have an opinion? 16:20:42 Guest has joined #css 16:20:42 astearns: Objections to closing this issue as resolved? 16:21:00 RESOLVED: Accept this edit and close issue 1552 as resolved 16:21:07 Topic: Classify pageup/pagedown keys 16:21:17 github: https://github.com/w3c/csswg-drafts/issues/1605 16:22:05 fantasai: We realized that page up/page down keys didn't have a classifcation so we proposed adding them to the intended item since it's basically understood to be a screen scroll. 16:22:43 MaRakow: I think page upa nd down make sense. Home and end are more challanging since with the previous resolution end might not get you to the end and most people expect home or end regardless of scroll-snap-stop. 16:22:47 home/end set expectation of actual top/bottom 16:22:48 fantasai: That's a really good point. 16:23:40 fantasai: One thing I would consider there is I think we put home & end under another classification...let me look that up. I could see an argument for hitting scroll-snap-stop because we have these internet things where you want to get to the end of an article and it just loads another. I'm okay moving them into the intended end. 16:23:45 TabAtkins: I'm okay either way. 16:23:48 +1 to keeping home/end sane 16:23:56 astearns: Draft has home and end in different? 16:24:02 fantasai: page up & down 16:24:06 TabAtkins: Directio + end point 16:24:13 fantasai: We can move to intended position. 16:24:14 tmichel has joined #css 16:24:30 present+ 16:24:43 astearns: Is ther any obj to making the change to page up and down to put in intended direction and endpoint class? 16:24:55 RESOLVED: make the change to page up and down to put in intended direction and endpoint class 16:25:06 astearns: And we'll take home and end out of intended direction class? 16:25:09 astearns: obj? 16:25:18 RESOLVED: take home and end out of intended direction class 16:25:42 astearns: Anything else before we update CR for scroll snap 16:26:08 ChrisL: I sent a Q about impl status. According to [missed] it's fully safari and partially by FF and Edge 16:26:17 TabAtkins: It's all an incompat subset of the old spec. 16:26:26 s/[missed]/caniuse/ 16:26:30 btw this is the caniuse URL http://caniuse.com/#feat=css-snappoints 16:26:36 ChrisL: Does that mean the browsers have tests is where I was going. transition request needs to say impl status. 16:26:46 it does mention support is partial 16:26:59 TabAtkins: We're nearly finished with our impl. I'm sure we have tests. I can poke Majid to see about grabbing them. 16:27:06 ChrisL: That would be great. Anyone else have tests? 16:27:41 Rossen_: For scroll snapping I think the current version isn't compat with the spec. We have tests but they're for the old version so not very helpful. I would encourage anyone with current test to contribute. 16:27:48 ??: We have tests but they're old 16:27:56 s/??/Myles/ 16:28:44 astearns: This needs to get on our list of spec rec next steps to get a test suite. 16:28:52 ok I will send a transition request 16:28:57 astearns: Anything more ChrisL? 16:29:12 ChrisL: No unless there's been additional wide review to mention. Apart from that I'm good to go. 16:29:18 astearns: Has anyone outside the WG looked? 16:29:25 TabAtkins: Aside from some impl I don't believe so. 16:29:32 ChrisL: I meant since Oct last year. 16:29:44 astearns: I don't believe we've sent it outside the group. 16:29:58 ChrisL: Okay. We did it when we first went to CR. It's in case there was antyhing else. 16:30:04 astearns: Obj to updated CR for scroll snap? 16:30:05 +1 16:30:11 RESOLVED: updated CR for scroll snap 16:30:17 rrsagent, here 16:30:17 See http://www.w3.org/2017/07/19-css-irc#T16-30-17 16:30:22 Topic: Computed value of float with absolute positioning when there is no box? 16:30:34 Github: https://github.com/w3c/csswg-drafts/issues/1436 16:31:58 fantasai: The issue is about if display has value of none 2.1 rules say position and flow don't apply and this short circuts the rest of display conputations. Normally if you have position absolute and float left float computes to none. If you have display none the computation doesn't happen. However, this becomes interesting with display: contents. What do we do for that one. 16:32:15 TabAtkins: This is where display: contents is the same problem as none, it's just someone is more freshly looking. 16:32:52 fantasai: Anything display: none due to parents the float computes to none. We propose any element with display: none , chidl of display: none or display: contents they all behave the same in respect to these transformations. 16:32:57 https://github.com/w3c/csswg-drafts/issues/1436#issuecomment-313215820 16:33:16 fantasai: We proposed specific edits in the issue. We'ld like a resolution to make them consistant and then a second for people tor eview the proposed edits. 16:33:33 dbaron: Idea is you make them consistant by always applying the rule where if position is absolute float is none. 16:33:40 TabAtkins: It's bad that it's inconsistant. 16:34:20 Rossen_: We already do...in all cases we would applyt hte rules and it seems FF and Chrome from reading the issue have a half and half where you do it for display: content but not display: none so you ahve branching somewhere. 16:34:23 jamesn has joined #css 16:34:31 dbaron: I'd be hesitant to have special rules for decendants. 16:34:32 present+ 16:34:58 dbaron: But I'd be okay to make them all float: none 16:35:18 Rossen_: There shouldn't be any special casing for decendants. I was highlighting that in this case you're not going to apply float computation rules, but with display: contents you will. If we all align and make it always apply then it will be more itnernally consistant and interop 16:35:42 TabAtkins: It matches IE always and Chrome & FF except in cases with display: none. Always applies is a small change. 16:36:04 s/float is none./float is none?/ 16:36:07 bradk has joined #css 16:36:08 Rossen_: I'm fine making the changes to css position. fantasai you said there might be changes to css 2? 16:36:14 Rossen_: Or is it css display? 16:36:44 fantasai: Yes for css2. There are edits in the issue. IT would be good for someone to check those 16:37:13 Rossen_: I did check, but those edits appear in css2.1 section 9.7 and in css position. I can reflect the position changes. Q is do we need to do anything on css-display 16:37:30 TabAtkins: I don't think so. Algo is only in 2.1 and position. There's nothing special in display. 16:37:33 Rossen_: Sounds good. 16:38:04 astearns: sounds like we need to resolve to make edits in css position. WOuld it make sense to make the edits, round of review, and then backport to css2? 16:38:15 TabAtkins: We were operating off 2.1 algo so we know what needs to be changed. 16:38:20 we resolved to request CR on css display in February. Is there some issue with the disposition of comments of the transition request? bert was handling it 16:38:23 astearns: So we'd resolve the change for both position & 2.1 16:38:26 TabAtkins: Yeah. 16:38:33 astearns: Obj? 16:38:47 RESOLVED: Make the changes listed in css2.1 and position 16:39:01 github-bot: end topip 16:39:01 dael, Sorry, I don't understand that command. Try 'help'. 16:39:05 github-bot: end topic 16:39:12 astearns: [reads ChrisL in irc] 16:40:03 fantasai: We resolved to publish display. Between resolution and prep transition request Orial (sp?) filed a ton of issues and we decided not to publish until we addressed those issue. We now have except a few on the F2F agenda. We can fix those and try again on CR. 16:40:08 ChrisL: Thanks. Good to know. 16:40:17 s/Orial/Oriol/ 16:40:49 ChrisL: DoC for Scroll Snap : https://drafts.csswg.org/css-scroll-snap-1/issues-cr-2016 16:41:03 TabAtkins: I suggest we defer #8 reconsider name of frames() timing function since we're still not at a stand still on GH 16:41:08 astearns: Can you remove agenda+ tag? 16:41:11 TabAtkins: Can do. 16:41:21 Topic: object-fit: scale-down should become a flag 16:41:29 github: https://github.com/w3c/csswg-drafts/issues/1578 16:41:43 fantasai: Can we do update WD of display? 16:41:51 astearns: I thought we resolved on that. 16:41:55 fantasai: Okay. 16:43:31 leaverou: Currently scale down is defined as contain or none. If contain wouldr esult in enlargement it's treated as same as none. This was defined at time cover was rare. Today we have a lot of images that are treated to cover the entire background. I'm sure you recognize this, we see it over the web. THe scale down behavior would be useful, but it's deinfed as contain or none 16:44:02 leaverou: It's unpredictable that it's defined tahat way based on the name. I suggested scale-down becomes a flag used with cover or contain. When it's on it's own it can be defined as contain. 16:44:17 leaverou: I discussed with fantasai and she agreed. We wanted to run by the group. 16:44:23 TabAtkins: Sounds reasonable to me 16:44:29 astearns: Other opinions? 16:44:52 astearns: Doesn't seem like there's a backwards compat because we can define scale-down by itesel. 16:44:57 ??: Is there a github? 16:45:00 https://github.com/w3c/csswg-drafts/issues/1578 16:45:01 astearns: Yes. 1578 16:45:29 s/??/iank 16:45:35 looks ok, thanks. 16:45:39 [pause for github reading] 16:45:46 I think this would be useful behaviour 16:45:56 astearns: I'm not hearing objections. Lots of positives 16:46:03 RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/1578 16:46:13 github-bot: end topic 16:46:22 astearns: We made it through the agenda. 16:46:35 TabAtkins: fantasai has issues we could add. 16:46:45 [debate over what to do] 16:46:45 https://github.com/w3c/csswg-drafts/issues/1611 16:46:57 Topic: Should last-baseline's fallback alignment be safe or unsafe? 16:47:05 github: https://github.com/w3c/csswg-drafts/issues/1611 16:47:57 TabAtkins: fallback alignment is used in 2 cases. If you trya nd use baseline- alignment but the element isn't in a context to do any baseline aligning it doesn't have a size it can baseline align. It ususe fallabck. Other is afte ryou've done the baseline alignment you then align the group according to your fallback alignment. 16:48:53 TabAtkins: Problem is with an end alignment do we use safe end or unsafe end. There's arguments on both. It's better to shift down when it's too small then to lose part of the content. I don't believe there's a strong author intent to go into the unscrollable. I think it both cases it's better to do the safe end alignment. 16:48:59 astearns: diff between safe and unsafe? 16:49:36 TabAtkins: If container is smaller then element end alignment aligns to two edges and you could get unscrollable. That's unsafe. Safe is if it happens we swithc to start alignment so it scrolsl down. 16:49:41 astearns: Got it. Seems reasonable 16:50:02 Rossen_: Last time we decided we fallback to end if we do last baseline. In an overconstraint now it's start? 16:50:16 TabAtkins: This is unrelated. IT doesn't trigger in the same cases as discussed last week. 16:50:20 Rossen_: Why not? 16:50:50 TabAtkins: Last week we were dealing with a stretching element forced by a max width to be too small. This is things large than the container. It's a different set of elements. 16:51:27 fantasai: Also it effects everything...you could interp 2 ways. 1 is we break alignment so if it overflows and the other doesn't we don't overflow. Or they continue to align and they both overflow and then do they align to bottom or top. 16:51:35 fantasai: OTher was just about one item and how it relates. 16:51:44 start and end rather than bottom and top 16:51:49 Rossen_: And this is because we fallback on end and we dont' have the problem with first because we fallback to start. 16:51:51 Rossen_: Got it. 16:52:02 I support Tab's proposal here. 16:52:03 Rossen_: Do we have any other cases where combination of end and unsafe is the default? 16:52:11 TabAtkins: I don't think anything else falls back to end. 16:52:20 Rossen_: Even in explicit end the default is safe? 16:52:26 tantek: Determined by layout mode. 16:52:35 s/tantek/ TabAtkins 16:52:53 Rossen_: Now if we have something fallback to end would safe and unsafe be based on layout? 16:53:09 fantasai: I think we changed it so everything is unsafe by default. This is a fallabck to it's different. 16:53:18 rachelan_ has joined #css 16:53:33 Rossen_: Now I'm starting to be less okay because we'll have cases were I forgot one property and half my items shift in weird ways and I don't know why. 16:53:58 TabAtkins: We're not proposing a control, so it's not leaving off anything. You shouldn't make that decision because it's a secondary alignment where the one you spec doesn't fully apply. 16:54:51 Rossen_: What I'm saying is I'll have two items, one last baseline one end. IN which case the one with last baseline it fallsback to end. IF we're not overconstraint they look same. As soon as you overconstraing one because scrollable and one not scrollable direct and that's weird and people will be confused. 16:55:12 Rossen_: That's why I wanted to walk abck from the behavior of the explicit end or start and what kind of safe/unsafe handling we have there. 16:55:17 fantasai: That's a fair point. 16:55:37 dbaron: You can specify safe start and safe end. IT's saying fallback for last baseline is safe end. 16:55:40 TabAtkins: Yeah. 16:56:18 Rossen_: What I'm tryign to say is if we made the explicit decision that everything fallback mostly to unsafe, why make an exception? If that's not the case maybe we revisit the fallabck to unsafe, but I don't see why to do that. 16:56:34 TabAtkins and fantasai : can't change unsafe fallack 16:56:55 Rossen_: We have the fallback to go back to end, can we try and do unsafe there ands ee if we have to change later with impl feedback? 16:57:31 TabAtkins: Without any way to change safe/unsafe (and we're not proposing a control) there's no way to get the otehr and the one value we can expose should be the one that guar. to not hide content. 16:57:42 astearns: I'm confused why it's better for this case but not the default. 16:58:18 TabAtkins: We already had centering and alignment based on margins in flexbox and that was safe. We made them do the other behavoir to let you get them. When we moved to alignment we felt it would be useful to allow a control. 16:58:28 astearns: It's just historical and backwards compat constraint. 16:59:21 TabAtkins: Maybe. Id on't think it was unreasonable for flexbox to default to unsafe because there was a control for safe. baseline-alignment can't mimic itself with margins. We either have to expose a toggle or make a choice and I'l like to avoid syntax complexity of a toggle for this edge case. 16:59:51 astearns: I can see both sides. I like that it will default safe so in this edge case you won't lose content, but since it's a tiny edge case I can see keeping it same as the other default alignment. 17:00:29 Rossen_: I'm going to be okay with either. I wanted to point out consistancy is always good. BUt I see losing content as bad as well which will happen with explicit end already. 17:00:59 astearns: We're out of time. I suggest we let log bot put this in the issue, let it sit for a week, and decide next week. If there are additional thoughts please add to the issues 17:01:03 github-bot: end topic 17:01:09 astearns: Thanks everyone for calling in. 17:01:10 Regrets for next week, in case I don't say so again. 17:01:42 regrets for next week from me as well (TAG meeting) 17:01:45 TabAtkins, I updated the specs with the resolutions on the call. Want to push out updates for css-display/css-align? 17:02:04 What you mean? 17:02:45 Those are just WDs 17:03:39 Ah, your asking me to do the echidna push. Yeah, I can 17:22:28 plh has joined #css 17:23:13 RRSAgent: stop