16:56:48 RRSAgent has joined #css 16:56:48 logging to https://www.w3.org/2020/01/15-css-irc 16:56:50 RRSAgent, make logs Public 16:56:51 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:58:03 svillar_ has joined #css 16:58:04 present+ dael 16:58:10 Scribenick: dael 16:58:13 astearns has changed the topic to: Agenda for Jan 15 call: https://lists.w3.org/Archives/Public/www-style/2020Jan/0004.html 16:58:54 present+ 16:59:00 tantek has joined #css 16:59:01 present+ 16:59:37 present+ 17:00:10 jensimmons has joined #css 17:00:17 present+ 17:00:49 AmeliaBR has joined #css 17:00:53 astearns: We'll give people a minute or two to join 17:01:20 present+ 17:01:44 present+ 17:01:45 present+ 17:01:50 chris has joined #css 17:02:15 present+ 17:02:35 present+ 17:02:39 astearns: We've got enough people to get going 17:02:39 present+ 17:02:55 present+ 17:02:58 astearns: Does anybody have any changes for the agenda? There's one we'll postpone that's far down on the list 17:03:03 astearns: Anything other than that? 17:03:18 fantasai: Scheduling? rachelandrew has been asking us for a lot of months to lock down summer dates 17:03:41 astearns: I don't think we can get to it on the call. We're waiting on Google people to confirm dates. Let's make sure we get to it at F2F next week 17:03:47 present+ 17:03:48 Present+ antonp 17:04:03 astearns: F2F is next week, we could use more agenda items. Please add them as soon as you can so people can be prepared at the meeting 17:04:05 Topic: [MQ] color-gamut Keywords 17:04:13 github: https://github.com/w3c/csswg-drafts/issues/4535 17:04:20 astearns: chris you commented last 17:04:55 bradk has joined #css 17:05:06 chris: I'm of the opinion this is shipped in 2 browsers so large change cost. If we designed now more generic names would be better but fact is Apple and others have shipped P3-gamut. 17:05:52 chris: We discussed hyphenation and got consensus on that and I don't want to rename them back. We went to display-P3 and then we'd have to rename and it would become ambig again. TabAtkins has a different opinion that they mean the same. I don't think they do mean the same 17:06:27 TabAtkins: I said they are approx the same. They're close to meaning same. Especially in ref2020 where one is a hypen and one not is extremely bad. p3 and display-p3 are different words. 17:06:40 s/is a hypen/has a hyphen/ 17:06:53 TabAtkins: Still of opinion we should be consistent. We shouldn't change color gamut so we should revert color function keywords because else people will ask why different 17:07:30 florian: I would argue mean the same. If you understand MQ to ask if gamut is supported by screen with this approx as large as this color space then it's yes. If screen isn't an exact match it's okay. You're not asking about color space specifically 17:07:41 chris: No one suggests renamining display-P3 to P3? 17:08:12 TabAtkins: I'm possibly in that relm. I would like ref2020 to be consistently hyphenless. P3 and display-P3 sound different. Hyphen diff shoudln't be 17:08:21 florian: I would align P3 to the one used in MQ. 17:08:24 faceless2 has joined #css 17:08:42 chris: Remember Apple wanted display-P3. When we reverted to what they wanted and what everyone talks about that's the name 17:09:03 TabAtkins: That's why I'm okay with display-P3. A subset of name in color gamut is okay. P3 means approx any of these. 17:09:28 florian: I don't think I would object to different P3. But your question was anyone suggesting we merge and I suggest we do. Won't object to don't 17:09:46 TabAtkins: Revert ref2020 in color to be hyphenless and leave p3/display-p3 alone? 17:09:50 chris: Okay with that.... 17:09:52 I would strongly object to having the only difference be the presence of hyphens 17:09:55 florian: Maybe hear from Apple? 17:10:06 smfr: Apple prefer to keep 17:10:22 astearns: Prop: Remove Hyphen from ref2020? 17:10:26 astearns: Objections? 17:10:27 s/ref2020/rec2020/ 17:10:32 s/ref/rec/ 17:10:47 RESOLVED: Remove Hyphen from rec2020 in all context; everything else stays as is 17:11:00 Topic: [css-pseudo-4] Original color of highlight pseudo inside ::first-letter/::first-line 17:11:08 github: https://github.com/w3c/csswg-drafts/issues/4625 17:11:34 fantasai: Currently spec if author spec background color and no color we use color of originating element 17:12:00 fantasai: With ::first-letter/::first-line it will cause it to change color b/c look at paragraph. Would be weird for spelling or grammar error. 17:12:11 fantasai: Do we make it look up ::first-letter/::first-line color or is that difficult? 17:12:40 TabAtkins: While I'm inclined to think it's complicated but heycam thought it was fine so sure. I think it's reasonable 17:12:45 astearns: Other impl feedback? 17:13:00 astearns: Prop? 17:13:12 fantasai: Use the color of the text prior to applying the highlight 17:13:14 Rossen_ has joined #css 17:13:21 present+ 17:13:23 myles has joined #css 17:13:33 fantasai: Whatever highlight being applied uses colors from before even if came from pseudo element like ::first-letter/::first-line 17:13:43 present+ 17:13:46 astearns: Any other pseudo elements effected? 17:13:58 fantasai: Not sure, possible ::before or ::after 17:14:15 fantasai: POint is make it clear if there's a pseudo element changing the color we use that color not the document element 17:14:21 astearns: Objections? 17:14:28 present+ myles 17:14:44 RESOLVED: Whatever highlight being applied uses colors from before even if came from pseudo element like ::first-letter/::first-line 17:15:11 fantasai: One note is currentColor keyword we'll have to make it resolve to a value for purpose of gCS. Will need to represent multiple colors 17:15:13 florian: Why? 17:15:29 Present+ 17:15:36 fantasai: If you have a selection...we attach selections to an element not ::first-letter/::first-line. Could change the model 17:15:39 florian: I see 17:15:47 ashwin has joined #css 17:15:47 fantasai: That's going to be interesting 17:16:07 florian: Yeah. For ::before/::after it's not a problem, but weird for ::first-letter/::first-line 17:16:16 fantasai: I'll try and spec it out. It will be complicated 17:16:31 tantek: Impact on impl with change? 17:16:39 fantasai: No one impl this right now. Would all have to change 17:16:57 chrishtr: Backwards compat? 17:17:11 fantasai: No one does this. It's difficult to impl I think. That's why I raised it 17:17:20 chrishtr: Good to have things not difficult to impl 17:17:29 fantasai: But good to have good behavior too. I can spec it 17:17:59 TabAtkins: I had same feeling as you but heycam thought it most reasonable to do. Since he doesn't think impl overrides correct behavior I decided to trust him 17:18:07 smfr: Is it to accept heycam proposal? 17:18:13 TabAtkins: Accept fantasai proposal 17:18:40 astearns: heycam was agreeing this is righ behavior to spec. We'll try and spec and get impl experience to say if it's reasonable. We can back out if too complicated to impl 17:18:56 present+ 17:18:58 tantek: I was revieing GH and saw fantasai question what to do. I didn't see the proposal. 17:19:10 fantasai: I need to write a proposal. Not worth it if no one wants to do it 17:19:18 tantek: Looks like heycam had a proposal 17:19:28 fantasai: There's two possibilities at a high level and heycam said this one 17:19:33 tantek: That's what we resolved on? 17:19:35 fantasai: Yes 17:19:40 myles: Why hard to impl? 17:20:26 fantasai: Highlight is attached to element in dob not firstline. So you can have a highlight span and have to look up different colors depending on if you're first line even if same element. You have to paint with different colors and have currentColor with presumably multiple colors. 17:20:49 fantasai: I don't know how machinery will work; needs substantial changes to make it work. We'll have to see what happens and how impl shake out 17:21:13 s/dob/doc 17:21:16 myles: My intuition is this wouldn't be difficult. In MacOS we draw highlight per element so it's just an if for us. iOS is different. I don't think would be hard 17:21:17 s/needs substantial/per-element ::selection needs substantial/ 17:21:23 fantasai: Okay 17:21:42 s/wouldn't be difficult/wouldn't be difficult to implement/ 17:21:45 florian: Clarification we resolved on high level principle and fantasai you're going to worry about how to do currentColor later. 17:21:46 fantasai: Yep 17:22:12 astearns: Next step if fantasai spec this out. Anyone with enough concern that it's a waste of time for her to work on this? 17:22:18 astearns: THen we'll let resolution stand 17:22:21 Topic: [css-pseudo-4] ::selection vs ::inactive-selection 17:22:29 github: https://github.com/w3c/csswg-drafts/issues/4579 17:22:32 drousso has joined #css 17:22:55 fantasai: Started discussing last week, came up with...discussion was why not have a MQ intead of two pseudos. Then we ran out of time. 17:23:03 present+ 17:23:11 fantasai: Do we want to go in that direction and drop inactive selection from spec and add a MQ to MQ5? 17:23:24 s/inactive selection/::inactive-selection 17:23:32 astearns: Use case for inactive MQ outside of selection? 17:23:45 fantasai: Probably. There's some JS methods that allow you to detect that 17:23:54 https://github.com/w3c/csswg-drafts/issues/4579#issuecomment-572188785 17:24:23 astearns: Main difference is instead of having to fully spec both styling you can do all your selection styling and have an inactive override to might reduce duplication 17:24:57 fantasai: We have to do that anyway b/c selection is when window is inactive. Whatever way we take it needs to apply. 3 ways to do it, 2 are in the issue and 3rd is do in a MQ where you can do inactive anything 17:25:35 AmeliaBR: Selection styles always apply active or not is what we have. DOesn't match browser styles. I like MQ idea and have benefit of being able to do things like pause animations and transitions which is more consistent with request animation frame transitions 17:25:57 smfr: Need to be a little careful with window activation. An iframe without focus is inactive color. It's focus state of document maybe. 17:26:18 smfr: Wondering case about inactive selection with the same document as active selection. There may be scenarios like that 17:27:04 AmeliaBR: Interesting. Then inconsistent with page visibility APIs concept of activeinactive. Useful to have specific examples of which browsers and OS conventions do have those distinguishments between this selection is preserved but not currently active and the cases where that can happen 17:27:33 astearns: I'd want to make sure the MQ had as much of same behavior as page visibility API. Doesn't seem like should be a difference if we can manage it 17:28:02 fantasai: Then it's not same as ::inactive-selection. When you have ::inactive-selection and ::active-selection in the same page we need the pseudo 17:28:48 fantasai: Other idea taken up during previous call was a selector on the element that says hey this element is focused so make selection this color. Some word that represents being selectable in an active way. Don't know if it would work 17:29:19 AmeliaBR: That would cover case of text area preserving selection even when text area doesn't have focus. A pseudo class on text area and then selection style with regular selection element? 17:29:52 fantasai: Yeah, I think so. but then...I don't know...need to think about cascading 17:29:54 Rossen_ has joined #css 17:30:04 fantasai: That's good points, we should move to another issue. We won't solve now. 17:30:24 astearns: I'm still interested to see if an inactive MQ would be useful, but may be out of scope for this problem 17:30:34 astearns: Let's continue in GH and maybe on agenda for next week 17:30:47 [css-sizing] intrinsic-size lost the thread 17:30:55 github: https://github.com/w3c/csswg-drafts/issues/4531 17:31:10 myles: Can we rename to something that makes more sense? 17:31:22 TabAtkins: If you can think of something, sure. 17:32:13 TabAtkins: Last month we talked about this and asked for any additional use cases beyond the major one that caused this issue and the minor cases we came up with after. Since then no one has commented. 17:32:25 TabAtkins: Suggests it's not important enough to think about over holiday at least 17:32:44 github: none 17:32:51 Topic: [css-sizing] intrinsic-size lost the thread 17:32:56 github: https://github.com/w3c/csswg-drafts/issues/4531 17:33:22 lajava has joined #css 17:33:59 TabAtkins: Given there's no additional suggestions our current proposal is revert back to a property with a default size for a contain:size element. Proposed name is content-placeholder-size. Happy to bikeshed. Makes it clear that it's a special case 17:34:21 TabAtkins: Objections or additional ideas on use cases with expanded form of content size please say so. 17:34:33 fantasai: I think if specific to contain it should be prefixed with contain. 17:34:39 TabAtkins: contain-placeholder is fine 17:34:47 myles: Placeholder a term of art for inputs? 17:34:59 fantasai: It's used for placeholder in inputs. I'm hesitant to use the word 17:35:05 TabAtkins: Where is placeholder in css? 17:35:09 ::placeholder and :placeholder-shown 17:35:13 dbaron: pseudo element and pseudo class 17:35:19 TabAtkins: Yeah, forgot about that one 17:35:29 ::placeholder and :placeholder-shown, I think 17:35:32 fantasai: contain-size unless you've got a good word in the middle 17:35:37 astearns: contain-initial-size 17:35:44 TabAtkins: initial or default seems reasonable 17:36:06 fantasai: If it's a flex item stretched it won't size to that size. contain-content-size maybe. Initial may not make sense 17:36:12 (it wasn't minuted, but I did say above that I wasn't aware of https://github.com/w3c/csswg-drafts/issues/4585 until it was mentioned today) 17:36:28 fantasai: I would prefer a word that clarifies in the middle 17:36:40 TabAtkins: contain-size sure 17:36:45 astearns: issues with contain-size? 17:37:04 astearns: Prop: Change the current contain:size to contain-size as its own property 17:37:13 dbaron, you could have posted suggestions into the original issue? But either way if you come up with something to add I'm sure we can reconsider. 17:37:14 chrishtr: it's a param to contain:size 17:37:29 chrishtr: contain-size is a param to contain:size that indicates non-zero 17:37:37 ??: Rename intrinsit-size to contain-size 17:37:43 s/??/cbiesinger/ 17:37:47 s/intrinsit/intrinsic/ 17:37:57 chrishtr: If contain:size is on an eleemnt we look to see if contain-size is set and then set placeholder sizing 17:38:06 TabAtkins: Contain-size is none or lengths 17:38:17 fantasai: contain-intrinsic-size? 17:38:53 astearns: Prop: Add contain-intrinsic-size property with an initial value of 0 that takes a pair of length 17:39:14 cbiesinger: Remain intrinisc-size to contain-intrinisic-size 17:39:19 s/remain/rename/ 17:39:30 chrishtr: And conditioned on contain:size being present 17:39:49 astearns: Prop: Have a contain-intrinsic-size property 17:39:55 bkardell_ has joined #css 17:40:14 dbaron: I missed the request for examples. I'd like to try and do that next week and get examples in the past 17:40:31 present+ 17:40:31 fantasai: Let's say if we do in this direction we'll do this and waiting on dbaron examples 17:40:36 is confused trying to follow this and can't offer a specific opinion. :/ examples would help. 17:41:03 florian: We mentioned initial value. For contain-size it's 0 for non-replaces which isn't always 0. Does initial value =0 and adds size or is it auto? 17:41:16 TabAtkins: Initial value of none. If you spec size it'll intercept 17:41:25 florian: Initial size of 0 it replaces? 17:41:27 TabAtkins: Yeah 17:41:45 astearns: TabAtkins can you commit to specing this out so we can have all the details and dbaron examples and see if it fits? 17:41:48 TabAtkins: Yes 17:42:34 fantasai: TabAtkins maybe spec both and we'll delete the one we don't select 17:43:01 dlibby- has joined #css 17:43:17 astearns: Let's get proposal and examples together and we'll look next week 17:43:18 Karen has joined #css 17:43:23 Topic: [css-sizing-3] max-content contribution of replaced only-ar elements might be improvable 17:43:34 github: https://github.com/w3c/csswg-drafts/issues/4218 17:44:28 fantasai: We triaged this last week. Case is we have some box which says I want width max-content 17:44:43 fantasai: Something inside it intrinsically sized with an aspect ratio and no size info 17:45:24 fantasai: No interop. Chrome is 0x0 as max content. Spec says use 300px width and ratio for height. Resolvable but arbitratry. FF uses initial containing block. That seems useful. We suggest spec FF behavior 17:45:31 astearns: Concerns? 17:45:46 astearns: Objections to Specify Firefox's behavior? 17:45:53 RESOLVED: Specify Firefox's behavior 17:46:07 Topic: [cssom] Table row resolved width and height 17:46:16 github: https://github.com/w3c/csswg-drafts/issues/4444 17:46:54 emilio: Height doens't apply to table rows depending on writing modes. There was interop issue found by jquery folks. A bunch of discussion on the issue. 17:47:04 emilio: Various options. Nice to get an agreement. 17:47:40 emilio: Webkit and Chrome behavior doesn't roundtrip. I propose to return computed value which is what we do for other elements that don't support height. People argued against that 17:47:59 TabAtkins: I'll proxy Alex and say FF is correct and roundtrip should work. Let's roll 17:48:11 astearns: Reading thread. What needs to be done to roundtrip height? 17:48:36 emilio: Using the computed value works. FF does give a resolved value it just roundtrips so not what I proposed. 17:48:42 emilio: Edge used to report auto 17:48:49 emilio: And the computed value 17:49:25 emilio: Computed value of auto FF gets a roundtrip height and Blink doesn't make sense. Edge returned computed value which is consistent with inlines 17:49:41 astearns: Prop: Return the computed value of height for table rows 17:49:54 emilio: When it doesn't apply which is not always. Depends on writing mode 17:50:22 emilio: I think that makes most sense. Alex argued for FF behavior. There are other comments from fremy and oriol saying computed value may not be most useful 17:50:29 emilio: A bunch of use cases for this 17:51:05 fantasai: Seems there are two discussions. One is which property applies and therfore has meaningful value. And which is in height axis of table. Then should prop of block axis return auto or used value. 17:51:34 fantasai: Mapping question should be switching based on writing mode of table. In terms of if we return used value or auto I don't have option other than it hsould round trip 17:52:00 fantasai: Means block axis on row needs to return. Can't default to auto. Inline axis doesn't matter 17:52:28 emilio: Used to have stronger opinion but I'm happy to keep discussing and figure out best compromise. If people don't have strong opinion 17:52:46 astearns: Leave that intent is to have round trip for block axis and leave it at that until we have actual text? 17:52:47 emilio: Fair 17:53:05 astearns: Concerns with having round trip value for block axis of table rows? 17:53:09 astearns: Let's work in issue 17:53:24 Topic: [css-text-decor] Consider adding an `all` value to `text-decoration-skip-ink` 17:53:32 github: https://github.com/w3c/csswg-drafts/issues/4277 17:54:28 myles: Right now when you turn on text-decoration-skip-ink you can use auto which is skip everything except cjk. cjk letters usually lower on line and intersect too much with underline. That was a decision I made many years ago; looked at cjk and it was awful so made it not apply 17:54:35 myles: Other value was none which is don't skip. 17:55:16 myles: Now that there's a property to move underline it's reasonable for an author to want to place underline such that it doesn't intersect. Then having ink-skipping on cjk makes sense. Let's add a 3rd value that does it on everything, even cjk. Makes total sense to me 17:55:26 I agree with doing this, would suggest using always rather than all 17:55:42 jensimmons: Makes sense to me to give authors rest of power to do what they want. They should have option to force it on even if default for script is off 17:55:48 florian: Makes sense to me 17:56:01 astearns: fantasai prefers always instead of all? Any other opinion? 17:56:18 astearns: Prop: Add an always value to text-decoration-skip-ink 17:56:20 astearns: Objections? 17:56:36 Jemma has joined #css 17:56:36 RESOLVED: Add an 'always' value to 'text-decoration-skip-ink' 17:56:49 Topic: Should mention the posibility to ignore custom cursors that go outside of the viewport 17:56:55 github: https://github.com/w3c/csswg-drafts/issues/3728 17:57:09 florian: Can spec image as cursor. If image is too large browsers expected to shrink 17:57:58 florian: Recently Chrome and FF fiured out security concern and they wanted to reject instead of shrink. I know they've tried things, reject or crop. I believe what they do is not what spec says. Maybe need to change spec to allow. Maybe experiment points to a right thing. 17:58:14 florian: I would like people experimenting to report their findings after doing it for a few months 17:58:49 emilio: In FF we fallback to next image or to default. We treat as invalid. You can't shrink b/c you can set a hotpoint and then need to shrink that too. I think Chrome did the same 17:58:54 emilio: I could be wrong on Chrome 17:59:09 astearns: Anyone know who looked at this on Chrome? 17:59:18 chrishtr: Need to follow up 17:59:38 florian: I'd appreciate follow up. 17:59:54 astearns: Let's see if we can get information on Chrome and continue discussion then 17:59:56 whoops :-) 17:59:58 Topic: end 18:00:02 zcorpan has joined #css 18:00:08 astearns: I'm told it's florian birthday so happy birthday 18:00:12 everyone: happy birthday 18:00:22 astearns: Safe travels everyone, talk to you then 18:00:40 thank you all! 18:00:50 happy birthday florian 🎉 18:01:18 chrishtr: I always get confused between you and csharrison :( 18:01:21 safe travels for everyone if you need anything during your time in Galicia, feel free to ping me 😉 18:01:27 florian: happy birthday :-) 18:01:45 LOL, not a problem. csharrison is Charlie Harrison 18:10:28 zakim, end meeting 18:10:28 As of this point the attendees have been dael, fantasai, rachelandrew, chrishtr, smfr, florian, jensimmons, oriol, dauwhe, cbiesinger, chris, rego, emilio, TabAtkins, antonp, 18:10:31 ... Rossen_, tantek, myles, dbaron, bradk, drousso, bkardell_ 18:10:31 RRSAgent, please draft minutes 18:10:31 I have made the request to generate https://www.w3.org/2020/01/15-css-minutes.html Zakim 18:10:33 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 18:10:37 Zakim has left #css 18:11:20 rrsagent, excuse us 18:11:20 I see no action items