15:56:59 RRSAgent has joined #css 15:56:59 logging to https://www.w3.org/2019/06/19-css-irc 15:57:01 RRSAgent, make logs public 15:57:01 Zakim has joined #css 15:57:03 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:57:03 Date: 19 June 2019 15:59:42 Present+ 15:59:49 ScribeNick: dael 15:59:57 present+ 15:59:57 present+ 16:00:29 present+ 16:01:08 present+ 16:01:19 present+ 16:01:36 present+ 16:01:41 present+ 16:02:04 present+ 16:02:15 present+ 16:02:30 Topic: Writing Modes 16:02:32 astearns: We've got all writing modes folks. At F2F I was told it was a week to get writing modes to rec 16:02:43 bradk has joined #css 16:02:49 smfr has joined #css 16:02:55 florian: It was a full time week of work, not a calandar week. Also with osme assumptions that need to be verified 16:03:02 Present+ antonp 16:03:23 present+ 16:03:24 florian: Assumptions there's one thing that needs to be checked for Gecko conformance. Sent an email to dbaron but haven't seen if he replied 16:03:32 astearns: Is there an issue for Gecko? 16:03:34 present+ 16:03:49 florian: dbaron did reply but I haven't read. There are failing tests for Gecko, but don't know if there's an issue 16:04:10 astearns: let's get back next week call or through github issues. Like to make sure there's an issue logged for changes in Gecko if that's the case 16:04:18 stantonm has joined #css 16:04:36 fantasai: I should spend time next week digging through impl report. 5 second look we had failing tests due to broken tests so some work will need to go into that. Don't know how much 16:04:44 astearns: Could I ask you to start that this week? 16:04:51 fantasai: I'm at AB meeting so no 16:05:18 astearns: By next week I'll expect to hear from florian about Moz issue. Then we can decide how much we can get done after that. I want to make steady work on this week to week 16:05:37 florian: Anyone hears this is 40 wrk hours with no one being paid to do it. 16:05:42 astearns: And that needs to be solved. 16:05:54 fwiw I filed https://github.com/w3c/csswg-drafts/issues/4026 in response to Florian's email 16:05:58 Topic: end 16:06:09 astearns: Anything to add or change in agenda? 16:06:11 myles has joined #css 16:06:11 Topic: Parent box of run-in or non-principal box 16:06:20 github: https://github.com/w3c/csswg-drafts/issues/3158 16:06:20 futhark has joined #css 16:06:27 present+ myles 16:06:37 fantasai: Trying to load this. I suspect this issue is just verifying something 16:06:44 chris has joined #css 16:06:48 astearns: This is where you asked for repub so maybe this should be the last. 16:06:48 present+ futhark 16:06:58 present+ 16:07:09 fantasai: I think we brought this in F2F when requested pub. I think we reviewed 16:07:31 astearns: And there are changes from a month ago. No changes to spec since F2F 16:07:46 fantasai: I think when we resolved to pub it was including these and we forgot to remove agenda+ 16:07:53 astearns: We did resolve to repub a month ago? 16:07:56 fantasai: Yeah 16:08:01 astearns: It's jsut not in this issue. 16:08:03 present+ 16:08:26 astearns: That was display. 16:08:35 fantasai: Yes, we don't have resolution for grid. Do for display 16:08:45 astearns: Should we re-resolve to publish display? 16:08:54 fantasai: I think resolution was in F2F but we can do it again 16:09:01 astearns: Objections to republish Display? 16:09:08 astearns: There's a DoC and a diff 16:09:12 sounds good to me 16:09:16 RESOLVED: Republish Display 16:09:25 rrsagent, here 16:09:25 See https://www.w3.org/2019/06/19-css-irc#T16-09-25 16:09:28 Topic: How to distribute space using flex ratios when the sum is 0? 16:09:32 github: https://github.com/w3c/csswg-drafts/issues/3694 16:10:16 fantasai: This was we forgot to handle divide by 0 case when dividing. minimal fix to only do that if the sum is >0. If sum is 0 we distribute space equally 16:10:17 https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079 16:10:20 fantasai: dif^ 16:10:59 fantasai: Refers to how we split up space for intrinsic track sizes. Have to distribute space even though it's flex 0. If there are flex ratios we can use we do. if they're all 0 we can't divide so we say do equally in that case 16:11:09 astearns: Any comments? 16:11:27 astearns: I don't see in diff anything about distributing equally 16:11:37 fantasai: [reads] 16:11:51 astearns: Alright so default case is in previous text? 16:11:54 fantasai: Yes. 16:12:02 astearns: Objections? 16:12:14 RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079 16:12:24 Topic: "Maximize Tracks" shouldn't distribute equally for flexible tracks 16:12:34 github: https://github.com/w3c/csswg-drafts/issues/3693 16:12:50 fantasai: this was another fix for errors 16:13:32 fantasai: There was a statement where we made a mistake saying treat max sizing same as min sizing. Trying to select a class of tracks and didn't use the right words. 16:13:48 astearns: Okay 16:13:59 fantasai: Just fixing an error. Happy is people want to look at it 16:14:17 astearns: Given issue discussion looks correct. oriol said it looks good 16:14:34 fantasai: These were co-edited with oriol so he thinks they're correct 16:14:45 astearns: Comments on this change? Objections? 16:14:55 RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/3693 16:15:06 Topic: Don't expand flexible tracks under a min-content constraint 16:15:15 github: https://github.com/w3c/csswg-drafts/issues/3683 16:15:52 fantasai: Case where spec forgot to consider min content correctly. Impl do logical and don't expand track to take up space. hcanging spec to match impl and do thing you expect which is size to smaller end when under min-content constraint. 16:16:24 fantasai: If you can shrink something down without overflow then min-content constraint should be that amount and not bigger. spec violated concept, impl did correct. Trying to match them up 16:16:35 astearns: Any comment? I not you asked for TabAtkins or Rossen_ to comment 16:16:44 fantasai: I'd prefer to get their + 16:16:49 TabAtkins: I'll review shortly 16:17:00 astearns: Resolve or wait? 16:17:11 TabAtkins: I trust fantasai so resolve. If I find a mistake I'll say something 16:17:36 Rossen_: On the same page. Proposed doesn't seem crazy, just need to look at overall algo fit. I'm sure fantasai spent more cycles so I trust her 16:17:40 astearns: Other comments? 16:17:49 astearns: Objections to this change? 16:17:56 RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/3683 16:18:22 astearns: All three of these look like they need tests or need tests verified. Have ther ebeen any? 16:18:33 fantasai: None in wpt yet. I'll check with oriol and he might know more 16:18:48 astearns: TabAtkins as you review can you check in tests? 16:18:50 TabAtkins: Sounds good 16:19:01 astearns: Once we have tests anything to keep us from updating CR? 16:19:16 fantasai: Prob tests for other things. I think most that should be fixed is but there might be one or two not. 16:19:21 astearns: I suspect no DoC yet. 16:19:29 fantasai: Right. Bulk of work is that and changes section 16:19:34 astearns: Anything else on grid? 16:19:44 fantasai: I'm going to say no 16:19:53 Topic: Combine forced-color-adjust and color-adjust properties somehow? 16:20:04 github: https://github.com/w3c/csswg-drafts/issues/3880 16:20:10 astearns: Was on F2F, didn't get to it. 16:20:45 fantasai: I think this would have been better at f2F. I don't know if there's anything for call. We need a concrete prop to discuss on a call that handles this issues 16:21:10 fantasai: If anyone is interested keep track of issue. Someone needs to make a proposal before we can move forward 16:21:16 astearns: Anything else before we punt? 16:21:44 AmeliaBR: I have a rough prop in the issue. More I think the more I think it's not worth it. I would be comfortable resolving no change but we can leave the issue open pending a good proposal 16:21:54 chris: I think they're better separate. dbaron comment is on the money there 16:22:05 astearns: fantasai think we should close no change? 16:22:19 fantasai: I'd give another couple weeks to see if we can solve dbaron concerns and if not we close it. 16:22:32 astearns: Any other comments? 16:22:41 Topic: Disallow repetition of color-scheme keywords? 16:22:53 github: https://github.com/w3c/csswg-drafts/issues/3848 16:23:53 I was trying but Tab can present 16:24:50 TabAtkins: for future extensibility we allowed arbitrary keywords and they're ignored. Question is what happens when you repeat color-scheme keyword? We don't want to disallow, but do we keep it in computed value? Collapse along the way? 16:25:04 TabAtkins: No strong argument either way 16:25:40 TabAtkins: originally thoguth there was an efficiency argument but that's not true if trying to preserve unknown. I think conclusion is keep the same and don't simplify. 16:25:48 TabAtkins: Just have computed value = specified value 16:25:50 I’m fine with either, it’s just that dropping duplicates means having to keep track of them during parsing 16:25:53 astearns: Any comments? 16:26:05 Which requires a hash map or something 16:26:07 astearns: So close no change? 16:26:13 TabAtkins: I don't recall current state 16:26:22 TabAtkins: Let me look 16:26:28 TabAtkins: It would be changing spec 16:26:30 Proposal is to resolve no change [in the value] :) 16:26:36 astearns: That computed is same as specified value 16:26:38 TabAtkins: Yes 16:27:07 astearns: Obj to computed value of color-scheme match its specified value? 16:27:14 RESOLVED: computed value of color-scheme match its specified value 16:27:24 Topic: What happens with multiple s? 16:27:33 github: https://github.com/w3c/csswg-drafts/issues/3846 16:28:14 TabAtkins: Meta name = color-scheme lets you set initial color-scheme so we can get that value out quick. What happens if you use multiple? Two obvious are take hte first or take the last valid one. Precedent both ways 16:28:35 TabAtkins: I propose we take the first so we get the value as quickly as possible so don't have to wait for rest of page to load before we apply effects 16:28:59 AmeliaBR: Since whole point of meta is to get it asap it does make sense. We have examples in HTML that are consistent 16:29:05 bradk has joined #css 16:29:12 TabAtkins: theme value also takes the first so it's consistent that way 16:29:45 fantasai: I would consider multiple to be an error case. If you're flipping colors constantly that's your fault. I think it benefits authors if we're consistent and agree with smfr it should be one rule for all meta tags 16:29:56 fantasai: Given oldest is viewport that means using last one 16:30:26 TabAtkins: Using last for viewport gives the bad behavior you listed. I think viewport fell out of viewport defined as eq to a stylesheet 16:31:13 fantasai: It's an error case. If author wants correct they should not ut multiple. I think it's fine if broken isn't correct. Consistant story for authors is more important that it's always last. Arbiraryness is more disruptive then having to keep all the things 16:31:45 TabAtkins: But if we have to take last, we can't render until have downloaded enough of HTML. I agree with consistency argument. I'd like to be consistent with first and see if we can adjust viewport. 16:32:03 q+ 16:32:06 fantasai: If you want to go that route it's fine. i think it's important we're consistent. If you want to see first is web compat that's good. 16:32:38 astearns: Sounds like we already have different. I'm concerned about hitching consistency to viewport given comment from futhark that viewport is last one inserted into doc. 16:32:49 TabAtkins: Yeah, ours is messed up. We shoudl not rely on viewport 16:32:52 ack smfr 16:33:19 smfr: before that comment I was reluctant on viewport. Changing viewport now does have more web compat concerns. I would love all meta tags to have sam.e need to figure out dynamically inserted nodes 16:33:42 smfr: UA might not process meta tags until end of head. Just because you have multiple doesn't mean you'll see flashes, UA can wait until end of head. 16:33:42 q+ 16:34:02 TabAtkins: Certainly can, but end of head could be different packet and flush the queue. Definitely different behaviors allowed. 16:34:03 ack myles 16:34:11 s/rely on viewport/rely on viewport behavior/ 16:34:27 myles: Procedurally meta tag is defined in HTML. If we decide something here is there anyone that can make edits to resolve this? 16:34:44 We are currently defining the meta value: https://drafts.csswg.org/css-color-adjust-1/#color-scheme-meta 16:34:47 TabAtkins: Should try and get agreement on consitent behavior and get that into general meta authoring guidelines 16:34:53 astearns: But this needs to be spec elsewhere 16:35:08 TabAtkins: Yes, actual definition is in HTML. They are deferring to us on this since we're defining it 16:36:01 astearns: I'm assuming that for web compat reasons we're not going to be able to change current viewport. Given that would anyone object to spec that the color-scheme meta will match theme-color and take first one found? 16:36:19 smfr: What happens with other meta like char-set? 16:36:33 TabAtkins: I do not know. But those are also more super legacy and likely to be weird 16:36:38 astearns: Would be nice to have answer 16:36:41 smfr: Agree. 16:36:49 fantasai: Don't want to resolve without jen or rachel 16:36:52 astearns: Fair 16:37:06 fantasai: I believe impact to author is bigger concern then get the earliest possible 16:37:32 TabAtkins: We've got 2 css things that are inconsistent so we'll have to change something. Maybe we have a new policy and legacy is legacy. 16:37:57 fantasai: If it's completely inconsistent and we can't align I'm fine with a going forward policy. If it's possible to align them all we should go that way 16:38:06 Or even to align most of them 16:38:12 astearns: TabAtkins can I ask you to do survey of meta tags that effect css? 16:38:27 TabAtkins: Looking at it. It's a consiquence of algo and not states so I'm chasing it down 16:38:43 astearns: let's wait on this issue until we get the survey and comments from authoring advocates. Sound good? 16:38:46 TabAtkins: mmhmm 16:38:57 Topic: column-fill should behave more similarly in paginated and continuous contexts 16:39:05 github: https://github.com/w3c/csswg-drafts/issues/4036 16:39:18 rachelandrew: Is dbaron on? He'll be needed 16:39:34 florian: I think I can represent 16:39:55 rachelandrew: There was a comment from Morton (sp?). Maybe worth waiting 16:40:02 astearns: Thanks florian but better to move on 16:40:05 github: none 16:40:13 Topic: Should option/optgroup be able to set counters? 16:40:25 github: https://github.com/w3c/csswg-drafts/issues/4004 16:41:10 TabAtkins: Technically per CSS they are decendent of replaced so don't generate boxes. if continuing the current resolution that counters work on box tree there's no box to let them set or change counter. Howveer FF and previous Edge allow it. Chromium does not 16:41:17 I'll take a better look at issue 3846 and see if I have any thoughts from the authoring pov. 16:41:25 TabAtkins: There are use cases for this and a chromium issue to fix and allow setting of counters. 16:41:46 TabAtkins: Chrome devs discussing if they should, bbut no conclusion 16:41:58 TabAtkins: This may effect related issues like if SVG elements can set counters. 16:42:34 TabAtkins: We need to figure out exact terminology. fantasai prop is go one level up to also things that are like boxes, but not css boxes for layout terms and allow those to host counters. 16:42:56 TabAtkins: I'm fine with that. prop is allow optin/optgroup and other things that are like boxes outside the css model to effect counters 16:43:03 astearns: sgtm 16:43:16 AmeliaBR: Makes sense. I'd like a more explicit definition to what is and isn't like a box 16:43:47 TabAtkins: I prefer to define a new term other specs could hook and we define what that is for HTML and SVG. Other mockups could say they are that thing even though they don't generate css boxes 16:43:51 astearns: Other comments? 16:43:59 s/mockups/markup languages/ 16:44:18 smfr: Sounds a little confusing for interactions with display:none. If you have optgroup that contributes to counters and you display:none it does it still contribute? 16:44:27 TabAtkins: I don't think display:none does anything to optin 16:44:42 smfr: If you have one of these how do you stop contributing to counters 16:44:52 Karen has joined #css 16:44:56 TabAtkins: You don't set the counter. the display:none wasn't an intentional choice, it was legacy 16:45:05 gtalbot has joined #css 16:45:27 smfr: Sounds like it will complicate code to determine what contributes to counters. May be odd interaction with other properties is what I'm saying 16:45:58 fantasai: I kinda disagree, I would expect diplay:none to have effect on counters. You're processing css properties and counters is one of them. I don't have strong opinion on this 16:46:15 TabAtkins: If someone with FF or older Edge can check that link I want to see if display has effect in other 16:46:21 smfr: [missed] 16:46:24 Display:none affected in firefox 16:46:31 webkit shows the ‘bar’ in the testcase 16:46:36 that is, removed from select rendering 16:47:14 Rossen_: We do not support counters inside of display:none. Only time we did something more interesting is if gCS was called inside and we'd have something to calculate in the sub tree. I think we backed it out because it was fragile 16:47:47 fantasai: I htink prop is that anything that is a replaced element has nothing to do with counters or we have something represented in render tree and not display:none and they can have counters 16:47:59 astearns: Either way impl would need to change b/c we're not interop 16:48:03 TabAtkins: Yeah 16:48:17 TabAtkins: And we're buckwild with what styles can effect inside a select 16:48:49 fantasai: If we have an idea we want to do this how aout TabAtkins and I come up with specific wording that deals with the issues brought up here. We can bring it back and htink about how it effects different impl 16:48:55 astearns: Objections to that path? 16:49:10 ACTION TabAtkins and fantasai develop spec text for https://github.com/w3c/csswg-drafts/issues/4004 16:49:11 Created ACTION-881 - And fantasai develop spec text for https://github.com/w3c/csswg-drafts/issues/4004 [on Tab Atkins Jr. - due 2019-06-26]. 16:49:24 Topic: counter scopes should be based on box tree, not element tree 16:49:27 github: 16:49:36 github: https://github.com/w3c/csswg-drafts/issues/674 16:50:02 TabAtkins: fantasai added the agenda. I'm curious why. There's a person asking about implications but don't know what to discuss 16:50:11 fantasai: I don't remember 16:50:32 astearns: We have a comment with different cases 16:50:57 TabAtkins: I need to look through his HTML cases to figure out what they're trying to favor. I think we have to defer for now 16:51:10 astearns: My reading is here are the cases that show a difference. not sure they're picking a side 16:51:25 Topic: make `text` of `leading-trim` interoperable? 16:51:27 I think the issue was https://github.com/w3c/csswg-drafts/issues/674#issuecomment-333541595 16:51:31 github: https://github.com/w3c/csswg-drafts/issues/3978 16:51:40 astearns: This is F2F leftover 16:53:03 koji: The leading-trim has text repesenting text-topa nd text-bottom. text-top and -bottom isn't browser interop or even on same browser across OSs. prop is to define. One prop is to use specific asender and descender. Another is em height. This isn't defined in CSS but algo is from geck 16:53:12 koji: Seems to do a good job for non-tall scripts 16:54:02 fantasai: I don't think I agree with a platform text value for this metric. I think people looking to trima re looking for a particular value. Does make sense to have other two, ascent, descent and em height. If we want to define an existing keyword to do that or add a new I'm less sure 16:54:15 fantasai: Interesting question of these metrics which do we want 16:54:31 myles: Like to not parse tables myself. Likely look up the functions. not sure if that defetes purpose. 16:54:38 fantasai: It means you cant read the metrics? 16:54:51 myles: Can but takes a lot of code to get the table and figure out the values and convert 16:55:02 koji: If you call core text ascendant and descendant aren't interop 16:55:03 s/metrics/sTypo metrics/ 16:55:32 myles: If there was a interop field we prop would jsut hook that field up to core text field which deferts purpose of interop field so that's unfortunate 16:56:21 koji: Clarify, the division of leading trim where authors use webfonts so it's the same bianary on all platforms and borwsers. If they use font-top they see different layout result. For this property I think having the same result for same font value is quite important 16:56:25 +1 to koji 16:57:04 astearns: Your last comment is that if for whatever reason web font is serving two values typo text won't be interop if metrics are different in font files. We're looking for interop if same font files is served. 16:57:25 astearns: I don't know if it's the case that if you have the same font file that the different text rendering systems will us OS2 table data 16:57:36 chris: Probably not. Was the case that they all used different tables 16:57:57 astearns: So even if we do spec that you have to get data out of font file we'd still end up with bad interop due to different text rendering 16:58:38 koji: Could be differences of rounding. Most of difference in font metrics comes from open type fonts having 3 different metrics and each platform uses different of 3. If browsers use same metrics should be interop 16:58:45 astearns: I'm not sure browsers are using same metrics 16:59:14 koji: Blink we use same metric as one platofrm uses. Even if same web fonts blink uses different metrics depending on platform 16:59:22 koji: We rely on platform API to read metrics 16:59:28 And this drives authors crazy 16:59:52 myles: meta question- if we resolve on this to have interop do you expect to apply this to other css properties. Like we'd have to implement new type system to get interop or is this one-off 17:00:28 koji: At least for new things I'd like itneroperable ones. Some reasons we may need existing ones, legacy reasons or future platofrm behavior. in those cases I'm fine to provide options. 17:00:32 +1 17:00:49 astearns: Should we continue later since we're at time? 17:00:54 myles: Good idea 17:01:01 astearns: Let's continue in GH and we'll come back 17:01:06 topic: end 17:01:12 astearns: Thanks everyone and we'll talk next week 17:01:40 futhark has joined #css 17:02:49 Ah how naive I was to think everyone would use the typographic ascender/descender eventually. From CSS2: https://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#cap 17:22:25 trackbot, end meeting 17:22:25 Zakim, list attendees 17:22:25 As of this point the attendees have been dael, plinss, astearns, Rossen_, fantasai, bdc, rachelandrew, florian, ericwilligers, koji, AmeliaBR, antonp, bradk, leaverou, myles, 17:22:28 ... futhark, cbiesinger, chris 17:22:33 RRSAgent, please draft minutes 17:22:33 I have made the request to generate https://www.w3.org/2019/06/19-css-minutes.html trackbot 17:22:34 RRSAgent, bye 17:22:34 I see no action items