16:00:29 RRSAgent has joined #css 16:00:29 logging to https://www.w3.org/2018/08/22-css-irc 16:00:31 RRSAgent, make logs public 16:00:31 Zakim has joined #css 16:00:33 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:00:33 Date: 22 August 2018 16:00:41 present+ 16:00:44 bdc has joined #css 16:00:47 ericwilligers has joined #css 16:00:47 present+ 16:01:06 present+ 16:01:07 present+ 16:01:08 ScribeNick: dael 16:01:09 present+ 16:01:10 present+ 16:01:33 present+ 16:01:36 chris has joined #css 16:01:39 present+ 16:01:54 Present+ 16:01:56 present+ 16:02:17 present+ 16:02:30 present+ 16:02:41 present+ 16:02:49 present+ 16:02:53 Rossen: One more minute and then we'll get going. 9:03PT 16:03:07 garrett has joined #css 16:03:11 Rossen: Let's get going 16:03:13 bradk has joined #css 16:03:18 present+ 16:03:26 Rossen: I wanted to ask if there are additional agenda items or changes to the current agenda? 16:03:28 tantek has joined #css 16:03:46 you saw my agenda+? 16:03:47 Topic: Static position should use content-box, not padding-box 16:03:50 github: https://github.com/w3c/csswg-drafts/issues/3020 16:04:24 Rossen: TabAtkins and fantasai noticed this while reviewing Grid and they asked if we should s tick to this or align to everything else. Opinions? 16:04:28 present+ 16:04:49 Rossen: TabAtkins is calling in 16:04:54 fantasai: I imagine he'sin favor 16:05:05 ^_^ 16:05:06 fremy has joined #css 16:05:09 makes sense to me 16:05:11 Rossen: We can resolve to align grid layout static position as content box rather then padding. Objections? 16:05:12 present+ 16:05:18 present+ 16:05:19 RESOLVED: align grid layout static position as content box rather then padding. 16:05:26 present+ antonp 16:05:38 Topic: Drop / defer border/background logical transforms 16:05:42 myles has joined #css 16:05:51 present+ myles 16:05:52 github: https://github.com/w3c/csswg-drafts/issues/3028 16:06:43 rachelandrew_ has joined #css 16:06:45 fantasai: This is to drop or defer border and background section. There'sa bunch of issues against it which we can handle but these were put in and sketched out on how to handle it. Parts critical for impl writing modes are not this 16:06:53 present+ 16:06:56 fantasai: We propose to defer this section so we can stablize the rest 16:07:11 fantasai: And address these in L2 if we think approach is good 16:07:17 https://drafts.csswg.org/css-logical/#background-and-borders 16:07:21 fantasai: Dropping all of section 5^ 16:07:31 Rossen: In favor, but want to hear if others have opinions 16:07:43 sounds good to me 16:07:44 +1 16:07:48 (I guess you didn't hear me) 16:07:50 Rossen: Objections to dropping section 5 from logical properties? 16:08:01 present+ 16:08:09 RESOLVED: Drop section 5, backgrounds and borders, from logical properties 16:08:11 topic: Should the mapping for logical values depend on the element or containing block? 16:08:13 Present+ 16:08:19 github: https://github.com/w3c/csswg-drafts/issues/3013 16:08:56 fantasai: Question was about should hte mapping for logical values depend on element or containing block. Not about logical properties, but values like float inline start or text-inline-start 16:09:25 fantasai: First thing is currently the spec...it was stated values compute to themselves. That's first question. Second is do you map against containing block or element. 16:10:05 fantasai: Supposed to depend on kind of element. test-align:start needs to map against element. For alignment we use containing block so makes sense to do same for float b/c you don't want element to move based on content, but rahter context 16:10:20 fantasai: Proposed is no change to spec but clarify the values map to themselves 16:10:35 fantasai: I copied that in. Does anyone else have comment? 16:10:59 Rossen: Question. There are...all properties in box model, are they defined to resolve against own writing mode? 16:11:29 fantasai: Yes own. It was sometimes correct and because you have to do computation of writing mode with cascade it's much easier computation. 16:11:54 fantasai: It's unfortunate that's t he case because there's a lot of cases to use containing block writing mode for something like margins but we did element's own writing mode for simplicity. 16:12:05 fantasai: Don't have same problem for values as they resolve at layout time 16:12:18 fantasai: We should have down issue 3 first as it talks about computed 16:12:35 [logical properties issue 3, not agenda issue 3] 16:12:40 Rossen: Other opinions? 16:12:49 #2821 16:13:29 Rossen: I asked about box model props because they are used for aligning box and sometimes used to align content inside. Align self and content align properties and values are very similar in layout impact so one doing self and the other containing block is weird. 16:14:01 fantasai: align self:start you use containing block, align-self:self-start you use your own writing mode 16:14:10 fantasai: text-align:start your children is what's being aligned. 16:14:43 Rossen: Get it. Not making case against it. In same virtue you can say position left and right can be used to align self and padding start and end can align content box. Fromm that PoV they are similar. 16:14:55 Rossen: For box model all properites and values compute to writing mode of element itself 16:15:03 Rossen: There is discontinuity here 16:15:07 Rossen: Can live with it. 16:15:44 Rossen: Other opinions or resolve on proposal to have values that effect alignment compute in containing block. Value effect alignment of content of a box o f an element are computed in writing mode of element itself 16:15:55 fantasai: That's what's spec in grid, flexbox, and alignment 16:16:03 +1 16:16:07 RESOLVED: Accept proposal 16:16:17 Topic: flow-relative values should say what their computed values are 16:16:25 github: https://github.com/w3c/csswg-drafts/issues/2821 16:16:46 fantasai: This is that the values we spoke about compute to self, not left or right. 16:17:13 fantasai: This is necessary for text-align property so for consistancy we should do that for all p roperties and if we don't do that CSSOM physical coord won't align 16:17:21 innovati has joined #css 16:17:59 dbaron: Flip side is that it means anybody looking at computed values to act on them has to do something more complicated. If a web page looks at computed value they need to consider 2x possibilities. They might not and therefore have bugs 16:18:20 fantasai: Yeah but you have to do for inherited prop s why treat non-inherited differently? 16:18:27 fantasai: You have to do that on inherited. 16:18:35 dbaron: Not as strong a case for not inherited ones 16:18:44 dbaron: [missed] or maybe not 16:18:56 s/[missed]/and I think there are more of them,/ 16:19:21 fantasai: Consistancy and so author can work in logical coord if they want to. Make these computed v alues be what they are and if browser needs to worry it should add convenience to its code before reporting to the user 16:19:25 dbaron: In the CSSOM 16:19:31 s/In/what about/ 16:20:07 Rossen: I think giving them all the values and having them make the choice what ot use would be better then the result of calc that will mask what value ended up computed and trying to piece that back to the value's origin. Esp. for inherited. 16:20:21 Rossen: I agree with dbaron it will require a bit more handling on user side but prob not that much 16:20:30 Rossen: We can always simplify later 16:20:33 alex_antennahouse has joined #css 16:20:37 dbaron: okay 16:20:51 Rossen: Other opinons or try to resolve? 16:21:02 fantasai: Also nec. if keeping previous resolution 16:21:08 Rossen: Yes, but we could revert. 16:22:03 Rossen: Objections to CSSOM exposes both logical and physical values and the resulting values are that of the cascade? 16:22:10 Rossen: Is that the summary? 16:22:33 fantasai: What..no. Resolution is that the flow relative keyword values compute to themselves, not to physical equivellents 16:22:39 Rossen: Objections to this? 16:22:53 RESOLVED: the flow relative keyword values compute to themselves, not to physical equivalents 16:23:05 Topic: publication 16:23:15 Rossen: This was last logical issue 16:23:23 fantasai: There's 2 more, but that's what we wanted to resolve before publishing 16:23:51 fantasai: Other 2 significant issues are marked in draft. 3030 and 3029. I think those need more time to discuss and publishing a draft with them marked is good way to go forward 16:24:20 Rossen: Agree. Objections to publishing a new CR for Logical properties? 16:24:21 fantasai: We're on WD 16:24:42 RESOLVED: Publish a new WD of logical properties 16:24:46 Rossen: We'll try for CR soon 16:24:59 Topic: containment vs baseline alignment 16:25:02 github: https://github.com/w3c/csswg-drafts/issues/2995 16:25:16 Rossen: TabAtkins can you do without florian ? Or do we punt? 16:25:26 TabAtkins: We concluded and wanted to see if obj. 16:25:50 TabAtkins: Spec wasn't clear what effect containments have on baseline. florian convinced me. Layout containment should censor the baseline b/c i t acts like there's nothing going on inside 16:26:06 TabAtkins: Don't have to do layout on contents to layout parent. Baseline requires you to know what's i nside 16:26:33 TabAtkins: Size containment does not censor. baseline doesn't effect that size in any way. Sizing works fine and you can baseline align 16:27:03 TabAtkins: Only potential weird is an overflow:visible element it can shrink to 0 but still have a baseline. That can happen today, though. 16:27:23 TabAtkins: Conclusion: layout containment censors baselines and size containment no change. Other containments don't matter here. 16:27:27 TabAtkins: Sound good? 16:27:36 Rossen: So this proposal only changes layout containment? 16:27:37 TabAtkins: Yes. 16:28:02 TabAtkins: urns out in chrome we don't pay attention to size but do for layout. We should be able to change. Per spec this only changes layout containment. 16:28:08 Rossen: Okay. Rest is clarification 16:28:13 +1 16:28:19 I think this is the correct resolution 16:28:19 Rossen: Reasonable. Seems florian agrees. Other comments? 16:28:42 Rossen: Objections to layout containment censors baselines and size containment does not 16:28:49 RESOLVED: layout containment censors baselines and size containment does not 16:29:03 topic: Define behavior for replaced elements 16:29:11 github: https://github.com/w3c/csswg-drafts/issues/1904 16:29:27 github: none 16:29:38 Topic: Selectors PR 16:30:27 chris: Selectors 3 was...we produced new CR and we have 1 test of the 1 errata. CR was just manditory for patent policy. That time has passed and there's no open exlcusion. So can resolve for PR. 16:31:12 chris: I see gsnedders asked about t est suite. He's got a pull request about build system not working for WPT. I don't see relevance. This CR is one errata and making it normative. I don't see this holds up PR and then REC. Selectors 4 is current spec. 16:31:23 Rossen: Is gsnedders on? 16:31:35 Rossen: I didn't see regrets from him 16:32:09 [seems like no] 16:32:13 chris: Do we move forward? 16:32:24 Rossen: I'm in favor. Want to hear from group. 16:32:27 fantasai: makes sense 16:32:28 +1 to PR from me 16:32:36 +1 16:32:37 Rossen: Objections to publish Selectors 3 as PR? 16:32:46 RESOLVED: publish Selectors 3 as PR 16:32:56 Rossen: chris do you need help? 16:33:06 chris: Fine. Done transition request except for resolution. 16:33:23 Topic: Define behavior for replaced elements 16:33:26 github: https://github.com/w3c/csswg-drafts/issues/1904 16:33:27 transition request here https://github.com/w3c/transitions/issues/83 16:33:47 rrsagent, here 16:33:47 See https://www.w3.org/2018/08/22-css-irc#T16-33-47 16:33:49 Rossen: Way replaced elements effected by break-inside properties 16:34:08 Rossen: Change we made with fantasai to go from a white list to a black list of properties 16:34:22 s/properties/elements/ 16:34:29 Rossen: Currently break-inside is spec that it applies to elements in normal flow that establish FC or are [list] 16:34:35 Changeset is https://github.com/w3c/csswg-drafts/commit/23d5a4c7b28f9767f7f7a621a7b895d4b858bbca 16:34:45 Rossen: Currently excludes flexbox, grid, etc. Changed that to be a blacklist 16:35:03 Rossen: Proposal is break-inside applies to all elements except [list from issue] 16:35:08 zcorpan has joined #css 16:35:23 Rossen: While we did this we noticed break-before and break-after weren't applied to grid and flex so we fixed that too 16:35:39 Rossen: That's the summary. Want to hear from WG if wemissed anything or if we can resolve 16:35:51 +1, blocklist and allowlist 16:35:54 plinss: Can we stop using term black list and white list? 16:36:04 Rossen: disallow list and allow list 16:36:15 Abspos includes fixed? 16:36:26 Rossen: Objections to accept the change: https://github.com/w3c/csswg-drafts/commit/23d5a4c7b28f9767f7f7a621a7b895d4b858bbca 16:36:42 Ok 16:36:48 Rossen: Yes bradk it includes fixed 16:36:56 RESOLVED: Accept the changeset: https://github.com/w3c/csswg-drafts/commit/23d5a4c7b28f9767f7f7a621a7b895d4b858bbca 16:37:07 Topic: Empty fragment at fragmentainer boundary 16:37:13 github: https://github.com/w3c/csswg-drafts/issues/1529 16:37:50 fantasai: About an empty fragment at a fragmentainer boundry. If you have a 0 height block or 0 width inline etc and the previous item that fi there filled the whole line does the 0 size element stay on the page? 16:38:05 fantasai: Specs don't say anything now about where required to break so UA can be intellengent. 16:38:12 fantasai: For 0 size might make sense to spec explicitly 16:38:28 fantasai: Question is do we want to spec that for fragmentation in general or just for flexbox? 16:38:44 fantasai: flexbox is only place w e define that percisely right now. 16:38:54 Rossen: I believe we discussedin the past. Don't remember if resolved. 16:39:11 because flexbox requires consistency more than quality-of-implementation, so its breaking rules are defined 16:39:41 Rossen: As far as I recall reason is the empty elements are exausted opportunitically as much as possible. If there are empty boxes at the end of fragment we assume they fit. Done so you can reduce subsequent fragments. 16:39:44 Rossen: That makes sense 16:40:06 Rossen: Other side is such elements or boxes are used for positioning or to create containing blocks or abspos items that go in and out for UI 16:40:40 Rossen: For those cases harder to argue it's better that such items are consumed asap or pushed. Again, counter is there are avoid break-inside and break-after properties where you can use such and control correctly 16:41:01 Rossen: In both cases makes snese to position and consume empty boxes a s early aspossible on frag where they are encountered rather then pushing 16:41:08 Rossen: That's how I remember previous 16:41:24 Rossen: Curious if there are other arguments or if we can resolve on that and spec it so we don't forget again 16:41:42 +1 16:41:44 Rossen: Obj to Spec 0 size elements are positioned as early as possible in the fragmentation flow? 16:41:55 RESOLVED: Specify 0 size elements are positioned as early as possible in the fragmentation flow 16:42:14 topic: publication 16:42:21 fantasai: Need to do DoC first 16:42:25 fantasai: Look next week? 16:42:29 Rossen: Fine 16:42:39 Topic: Consider adding a third value (skip?) for text-decoration-skip-ink 16:42:43 github: https://github.com/w3c/csswg-drafts/issues/2818 16:43:21 Rossen: astearns you added this from the F2F. I wanted to hear from Amelia or myles or anyone involved 16:44:02 myles: This is asking for a distinction between off/on/do what platform does. For us on and do platform is the same. Proposal asks for explicit on. I wanted to knwo what other vendors thought about skipping on by default 16:44:18 fantasai: I don't think it's by default. Request is a value, doesn't mean we change initial. Initial is auto. 16:44:26 Rossen: Do we need auto? 16:44:34 fantasai: Yes. Wanted to allow UA to do what it felt like. 16:44:47 myles: Cool if all browsers decided default was do skipping so we could have 2. 16:45:43 Rossen: Our position is we just finished re-write inline layout. ink-skipping was on my shortlist, but that shortlist wasn't short so we didn't get to it. As a targetted behavior we'd want on by default once we have it. Just like w e enable kerning by default. Doable, not super concerning for perf. 16:45:50 myles: Sounds like you're okay with 2 values 16:45:52 Rossen: Yes 16:45:56 myles: We are also happy with 2 16:46:24 Rossen: Having said that there's now ay to force it. If platform supports but if i t decides on that device it disables you can't force it. 16:46:38 myles: When you produce a product that can have that behavior we can re-open? 16:46:40 Rossen: Fine. 16:46:52 Rossen: Is Amelia on? 16:47:03 s/Amelia/Emilio/ 16:47:08 dbaron: I don't think xidorn wanted it on for all 16:47:14 myles: Do you remember reasons? 16:47:33 dbaron: I think some w as related to what he saw as default on platform. Maybe windows primarily. 16:47:53 dbaron: Don't remember that well. Underlying was xidorn wasn't comfortable with on by default for all. 16:48:02 myles: Maybe let this go into issue and ask him to comment in issue? 16:48:02 Rossen: I'm on IRC fwiw (can't get on the call today :() 16:48:13 fantasai: Yeah. Can also take up on Sept 5 call 16:48:16 myles: Sounds good 16:48:20 Rossen: Sounds reasonable. 16:48:26 Rossen: Let's stop here and move on. 16:48:35 Topic: 'overflow-block' and 'block-overflow' are too similar 16:48:43 github: https://github.com/w3c/csswg-drafts/issues/2561 16:48:49 https://github.com/w3c/csswg-drafts/issues/2561#issuecomment-413144634 16:49:05 Rossen: florian is not here. Dunno if heycam or rachelandrew_ are here 16:49:16 fantasai: I'min favor of accepting proposal in last comment fwiw 16:49:36 Rossen: Other opinions? 16:49:40 rachelandrew_: I'd agree 16:49:45 +1 to block-ellipsis 16:50:00 Rossen: Rename overflow to block-ellipsis. Rename auto to none. Rename ellipsis behavior to auto 16:50:20 rachelandrew_: Yes I agree [missed] 16:50:57 rachelandrew_: I agree and as Imentioned in comments I wrote docs for MDN and this seemed sensible way to explain it 16:51:19 Rossen: We can try and resolve. Objections to Rename overflow to block-ellipsis. Rename auto to none. Rename ellipsis behavior to auto 16:51:31 RESOLVED: Rename overflow to block-ellipsis. Rename auto to none. Rename ellipsis behavior to auto 16:51:45 Topic: font-size: 'medium' value is the user's preferred font size 16:52:02 github: https://github.com/w3c/csswg-drafts/issues/2430 16:53:09 chris: It seems...I thought this effected impl and rereading i t looks like this should be t he users default, apperently it already does impact medium. it's restoring language that was in the spec and was removed. Thought it was a change, but I no longer object. We can put the language back. I'd like to hear i f other vendors see a problem. Otherwise trivial change 16:53:25 bradk has joined #css 16:53:57 myles: One thought. Proposal has changed through issue. In Apr 25 post from Amelia it says [reads]. I think that's more specific than original text. Helps me understand what text trying to say. If we make a change, should be one Amelia proposed 16:54:04 Rossen: You're okay with changes? 16:54:05 myles: Yeah 16:54:45 dbaron: One thing we've found in past is if you change the meaning of medium and default font size meaning many web pages break. Turns out to not be a good thing rather then zooming. Maybe that's changing as web changes 16:55:17 myles: One detail, we don't support changing meaning of medium, but do support bumping every font size by a %. No way to effect keywords without effecting font-sizes and that works well 16:56:05 chris: I thinkt hat was the basis for my original reluctance. We seemed to hope that would work in CSS 1, but now you can zoom entire page and that seems more robust and what people do. didn't want to restore on basis of it was in css2. 16:56:35 myles: Q for dbaron. If you change definition of medium to other then 16 pages break, but someone in the issue said chrome and ff allow changing definition of medium 16:56:55 dbaron: We do have a setting and over time it has gotten more hidden, but haven't removed. It's not a great idea to set. 16:57:15 I have changed that setting and have had pages break 16:57:15 Rossen: What does that leave for this issue? 16:57:20 so we shouldn't really encourage changing it, then 16:58:08 myles: This is a natural pull between browsers custom a11y that they do without spec changes vs something normative the spec can say about how to improve font sizes. dbaron comment on how browsers evolved their solution and maybe normative spec text isn't nec makes sense. Could go either way 16:58:21 chris: Could go either as well. Don't want to encourage people to do a bad practice 16:58:26 Rossen: Leaning resolve no change? 16:58:37 I don't think we have enough data to justify a specific change on this 16:58:37 fine with no change here if WG so resolves 16:58:45 Rossen: Going to take silence as agree 16:58:48 +1 16:59:02 Rossen: Objections to no change to spec, leave piece of text out 16:59:07 +1 16:59:11 RESOLVED: no change to spec, leave piece of text out 16:59:15 topic: end 16:59:36 Rossen: We're at top fo hour, one more font issue from fantasai 16:59:56 Rossen: Happy to push if can't resolve 17:00:04 Rossen: Okay, we are done 17:00:11 Rossen: We'll chat next week. Bye! 17:00:27 trackbot, end meeting 17:00:27 Zakim, list attendees 17:00:27 As of this point the attendees have been antenna, Rossen, dael, dauwhe, ericwilligers, bdc, plinss, tgraham, dbaron, chris, astearns, melanierichards, jensimmons, fantasai, 17:00:30 ... garrett, zheng_xu, tantek, TabAtkins, antonp, myles, rachelandrew_, leaverou, bradk 17:00:35 RRSAgent, please draft minutes 17:00:35 I have made the request to generate https://www.w3.org/2018/08/22-css-minutes.html trackbot 17:00:36 RRSAgent, bye 17:00:36 I see no action items