16:00:33 RRSAgent has joined #css 16:00:33 logging to https://www.w3.org/2019/05/15-css-irc 16:00:35 RRSAgent, make logs public 16:00:35 Zakim has joined #css 16:00:37 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:00:37 Date: 15 May 2019 16:00:50 present+ 16:00:52 Present+ antonp 16:00:56 present+ 16:01:33 present+ 16:01:35 present+ dael 16:01:41 ScribeNick: dael 16:01:43 present+ 16:01:50 present+ 16:01:54 present+ 16:02:07 Rossen_: Let's start at 9:02PT 16:02:22 present+ 16:02:32 Rossen_: Let's get started 16:02:40 present+ 16:02:41 Rossen_: As usual, I wanted to call for any extra agenda items 16:02:52 Present+ 16:03:01 Topic: Rescope :has to static CSS rather than .querySelector 16:03:10 github: https://github.com/w3c/csswg-drafts/issues/3925 16:04:00 bkardell_ has joined #css 16:04:07 present+ 16:04:07 fantasai: It was pointed out nobody impl :has not even in query selection. Spec should align with reality and not say you can use it. it is impl in Prince XML so maybe needs to stay in spec but scope to PDF renderers 16:04:46 florian: I think we discussed in the past and wanted to ban it from PDF engines as well b/c worry it would creep out of that narrow use case and we'd be stuck for compat reasons. Or something along those lines. Couldn't find minutes 16:05:09 fantasai: We did. And that's why it explicitly says shouldn't be used in CSS but reality is that's not what's happening 16:05:24 Rossen_: If this is reality than what fantasai suggested makes sense 16:05:33 Rossen_: Any additional comments or challenges to this? 16:05:52 florian: Okay changing .querySelector but not sure about PDF render 16:06:01 fantasai: Reused a definition about static not dynamic 16:06:08 florian: Does [list of things] count? 16:06:11 q+ 16:06:12 fantasai: Up to impl if it counts 16:06:16 Rossen_: It is impl specific 16:06:44 fantasai: If you don't like this division either we remove and people are non-conforment or we convince more people to impl. So what do you want to do? 16:07:32 florian: Since existing impl violates spec about if they should impl and if we put a feature in the spec saying this is a thing you may or may not want to impl sure. I don't know if static render definition makes a difference, but if browsers aren't worried about creeping out sure 16:07:41 dauwhe: Other instances of infections creeping out? 16:07:51 florian: Intentionally yes, accidentaly not sure 16:07:54 dauwhe: Seems low risk 16:08:11 AmeliaBR has joined #css 16:08:13 fantasai: It's not we dont' want this in browsers, it's that no one has figured out how to do it in a performant way. 16:08:21 present+ 16:08:22 fantasai: If a browser figures out how to do it we'd be happy 16:08:35 florian: Keep in spec, remove profile distinction, mark at risk 16:09:20 q+ 16:09:24 Rossen_: Have enough features not implemented, reducing that is a great goal. Lingering things in spec that's an idea that won't happen isn't good. There's history in github and repos that people could find. I'd move forward to drop now and if people want to make a case they will 16:10:06 +1 to what Rossen_ said 16:10:30 bkardell_: Sorry, didn't have sound early in call. We added distinction between profiles b/c it could easily be impl in JS in theory. I think we hear people saying it doesn't add much, I disagree with that. Isn't the way the spec is written, I thought it was specifically because if a vendor wanted to experimentally impl in full profile that's okay. Is that not the case? 16:11:01 florian: Spec says browsersplease don't do this. We didn't want someone to ship while others didn't know how. If that was a good idea is sep. question, but spec says must not impl in CSS< only JS. 16:11:40 florian: To Rossen_ point it's not just not going to happen, it's not going to happen prob in browsers, but it is happening in other vendors with the name. We put at risk, push to L5 if we go to rec 16:11:48 Rossen_: Should we then spec other features in JS library? 16:12:01 florian: It's a feature we specced rendered by a CSS. Just not a browser 16:12:17 bkardell_: It's in jQuery for same reason, because it was in CSS when it was rewritten 16:12:29 florian: Maybe we go to rec with 2 impl, jQuery and Prince. A bit of a stretch 16:12:57 florian: I feel bad removing it after it's impl in several places and freeing up the namespace doesn't sound nice. 16:13:13 bkardell_: is that really the order of things, I thought jQuery had it prior to any spec text existing 16:13:45 fantasai: I think disingenuous to remove completely given there is an impl of something standardized. Seems like we only put things in spec if a browser impl but another non-browser impl isn't worthy. If this was webkit not Prince we wouldn't talk about drop 16:13:55 bkardell_: What if Webkit only did it for print stylsheets 16:14:04 fantasai: We be conforment to spec 16:14:14 bkardell_: I think florian just said it would violate current spec 16:14:24 florian: Yes b/c extra restriction 16:15:25 AmeliaBR: Question now is this whole idea of live vs snapshot profiles, is it impl anywhere? No one is impl things for .querySelector that's not for CSS. Only UA that does .has is as a css selctors. That part of spec needs reconsider, but what direct? .has is not in spec or drop the profile idea? 16:15:33 florian: I'd go with later and mark at-risk 16:15:36 fantasai: and optional 16:15:47 florian: I don't know what difference it makes but okay 16:15:53 fantasai: Means not required to conform 16:15:59 bkardell_: So Prince is in violation? 16:16:05 florian: Is now, but if we do this it wouldn't be 16:16:21 bkardell_: Can someone recap? Remove the profile notion and mark at risk and options? 16:16:43 fwiw i agree with rossen_, but i'm also okay with moving it from L4 to L5 as a compromise 16:16:44 fantasai: At risk makes it easier to remove later. It's a process thing. Optional means you can be conforment to module without doing this 16:17:01 AmeliaBR: It's separate module you can impl or not but it's tucked inside main selectors 16:17:14 fantasai: Yeah. When first did profiles there were many features, but now there's just this one 16:17:24 bkardell_: If someone impl for .querySelector only it's okay? 16:17:25 fantasai: Yes 16:17:36 bkardell_: And a print stylesheet or static processing engine that's okay? 16:17:38 fantasai: Yes 16:17:40 bkardell_: sgtm 16:17:59 Rossen_: Nearing consensus. Any other additional thoughts before we move this to L5 and mark at risk? 16:18:23 AmeliaBR: How is @supports selector supposed to work with selectors impl only in JS and not CSS. Separate issue. 16:19:11 florian: Another point. In past other proposed selectors such as focus-inside that were initially rejected by bodies because we have :has. We can rebuff with saying browsers don't do it. Can now with intent to impl 16:19:37 bkardell_: Begs the question of lots of documented use cases of possible withins that are solved by this. 100 withins is not wonderful thing 16:19:54 fantasai: I think we should tackle that in separate issue 16:20:02 fantasai: There's various approaches we can take 16:20:03 also sgtm to tackle in another issue 16:20:22 Rossen_: Agree. Objections to resolve by move this to L5 and mark at risk and optional 16:20:24 +1 to leave in l4 16:20:40 fantasai: Leave in L4. It is impl. This isn't even CR yet. We're not trying to trim to 2 implementations yet. 16:20:45 florian: At risk is enough. 16:20:56 Rossen_: That's fine. Mark this as at risk and optional 16:21:07 RESOLVED: Mark this as at risk and optional, remove profile 16:21:15 Topic: lazyload 16:21:23 github: https://github.com/w3c/csswg-drafts/issues/3659 16:22:06 Rossen_: gregwhitworth is IRC only, let's do this later 16:22:08 github: none 16:22:09 github:none 16:22:17 Topic: pre-wrap and tabs at the end of the line 16:22:24 github: https://github.com/w3c/csswg-drafts/issues/3869 16:23:00 fantasai: I summerized issue. No agreement on if tabs can hang at end of line. ONly use case is tab separated value files. No clear direction 16:23:21 florian: I was actioned to give examples and haven't. Agree with fantasai we agree on break spaces, but pre-wrap is tricky. 16:23:29 Rossen_: Remove from agenda until have test cases? 16:23:37 florian: May also want to do break-spaces 16:23:58 Rossen_: Let's look at everything at once. Otherwise you might find some new evidence and we need to re-open 16:24:03 Rossen_: I'll remove agenda+ 16:24:12 Topic: When to/not to include preserved trailing spaces 16:24:21 github: https://github.com/w3c/csswg-drafts/issues/3440 16:24:37 Rossen_: Is koji on? 16:24:56 fantasai: If koji isn't we should defer. Maybe koji florian and I do a separate call. No clear idea of what we should do. 16:25:20 Rossen_: No issue with that. If you move the conversation and then we can come back either before F2F or at F2F. 16:25:33 florian: sgtm 16:25:37 Topic: Define crossorigin, preload and async URL modifiers 16:25:45 github: https://github.com/w3c/csswg-drafts/issues/1603 16:26:23 AmeliaBR: I didn't put this on the agenda, chris did. Is he on? 16:26:37 Rossen_: I don't see regrets, but he might still be on vacation 16:27:02 Karen has joined #css 16:27:41 AmeliaBR: We talked about this at last F2F. We resolved some syntactic details about URL functions with modifiers. General consensus we should pursue harmonizing with HTML for image loading modifiers. Waiting on someone to sit down and write a proposal. I haven't done that. Not sure what Chris wanted to do on call 16:28:11 Rossen_: If we need to wait that's fine. I'll remove agenda+ so that it doesn't come back until it's ready. 16:28:14 Topic: lazyload 16:28:25 github: https://github.com/w3c/csswg-drafts/issues/3659 16:28:32 Rossen_: Don't know if gregwhitworth made it 16:28:51 gregwhitworth: I'm here 16:29:48 gregwhitworth: This isn't my issue, but I dug into what I think this person wanted that bg images weren't be loaded by lazyloading. I'm not sure what this person wanted so I suggest we close until more clarifiction. Chris pointed out there is already an issue from AmeliaBR about modifiers. I'd close as dup and ask for more details. 16:30:00 Rossen_: Close the issue back to the owner and ask for more details? 16:30:19 gregwhitworth: I pinged him and asked to clarify. I'd close as dup to the one Chris L referenced. 16:30:31 Rossen_: Any other members that read or want to discuss this? 16:30:36 Rossen_: If not we can do that 16:30:52 Rossen_: No hearing takers. I'll clear up the labels and move the issue back to the owner 16:30:54 Topic: end 16:31:03 Topic: republish Values 3 16:31:30 fantasai: We discussed bracketed range notation at last F2F. TabAtkins and I folded that in last month. We need to republish. It's a CR 16:31:38 Rossen_: Sounds good. 16:31:52 florian: This new thing is arguably editorial. The bracket notation. 16:32:01 Chanes list https://drafts.csswg.org/css-values-3/#changes 16:32:03 Rossen_: Still want to have WG resolution 16:32:13 florian: Just that it's the lighter form or republication 16:32:15 New section is https://drafts.csswg.org/css-values-3/#numeric-ranges 16:32:21 Rossen_: Trying to gauge if people want time 16:32:37 AmeliaBR: I do have an open PR. Trusting that'll get integrated before republication 16:32:42 florian: Doesn't have to be before 16:32:59 AmeliaBR: It includes Values 3 edits. It's clean up on top of what fantasai pushed. Major ones are already on there. 16:33:11 Rossen_: Do you have PR? 16:33:16 AmeliaBR: #3894 16:33:16 https://github.com/w3c/csswg-drafts/pull/3894 16:33:43 fantasai: Happy to add in the changes you're suggesting, but I will want to hold off on merging changes to other specs until after Values 3 is published. 16:33:52 Rossen_: Values 3 changes are straightforward. 16:33:58 Amelia's changes https://github.com/w3c/csswg-drafts/pull/3894/files#diff-c3798e248ee6e7eeb80c7b12f053a5de 16:34:04 Just Editorial fixes 16:34:31 AmeliaBR: My changes are minor. fantasai already merged major changes into ED which introduce new syntax. Is definiting a new sytax with no normative effects on impl is that sufficient to count as editorial change for CR 16:34:34 fantasai: Good question 16:34:37 Rossen_: Not sure 16:35:06 AmeliaBR: florian, does this count as editorial where we define new syntax but it has no normative impact requirements. 16:35:14 florian: I don't think process is clear. Probably isn't editorial 16:35:27 fantasai: Change to spec convention of how they describe, but doesn't change definition 16:35:50 florian: Definition of what's editorial is quite limited and probably this isn't under it. Borderline probably not editorial. 16:36:23 florian: There's 2 categories of what's editorial, Markup and titles/grammatical error but correcting clarification is not editorial. I think that's all that editorial 16:36:26 bkardell_: Is this the second? 16:36:30 florian: It's not a bug in an example 16:36:34 bkardell_: Clarifying. 16:36:50 florian: Clarifying non-ambig. You'd have to make the argument it's not obvious 16:37:10 fantasai: I don't think we care. If it's REC might be worth quibbling. It's CR let's go through normal process. 16:37:14 Rossen_: [missed] 16:37:24 hober: If this is change in webIDL it's not a hard question 16:37:29 florian: Same kind of question 16:37:33 s/quibbling/quibbling, updating a REC requires like three publications and an AC vote/ 16:37:55 +1 to fantasai, let's just do it. 16:37:56 hober: Trying to say it is a change that impacts specs that depend on it. I think it's okay that it's not editorial 16:38:00 s/this is change/this were a change/ 16:38:02 Rossen_: Seems to be agreement around that 16:38:14 Rossen_: Anyone need additional time to review? Or we can resolve 16:38:22 Rossen_: Objections on Republish CR of Values 3 16:38:28 florian: With AmeliaBR's PR? 16:38:41 Rossen_: Yes since AmeliaBR PR doesn't introduce anything that changes the way this would be republished. 16:38:52 AmeliaBR: And if fantasai wants to cherry pick markup fixes that's fine. 16:38:58 Rossen_: I'm sure fantasai will figure it out. 16:39:01 Rossen_: Objections? 16:39:08 RESOLVED: Republish CR of Values 3 16:39:14 I have reviewed the multicol part of that PR, that too can be landed 16:39:15 Rossen_: fantasai you'll handle this? 16:39:21 fantasai: Yes, I can 16:39:32 TOpic: F2F 16:39:45 dbaron: Please make sure you have listed yourself as an attendee and if you're attending Houdini 16:39:58 dbaron: If you have dietary requirements please email me. 16:40:07 Rossen_: Should we add a column for that on the wiki? 16:40:18 dbaron: I've got a bunch in emails so I'd prefer that. 16:40:32 bkardell_: How would you like us to err on maybe attending 16:40:42 dbaron: Put yourself on the list and put you're a maybe. 16:40:49 https://wiki.csswg.org/planning/toronto-2019 16:40:52 Rossen_: Thanks dbaron. Please add yourself if you haven't 16:40:57 Rossen_: Anything else? 16:41:03 Topic: end 16:41:14 Rossen_: Everyone gets back 20 minutes. Thank you 16:41:27 trackbot, end meeting 16:41:27 Zakim, list attendees 16:41:27 As of this point the attendees have been dauwhe, antonp, Rossen_, smfr, dael, plinss, tgraham, oriol, melanierichards, florian, dbaron, fantasai, bkardell_, AmeliaBR 16:41:35 RRSAgent, please draft minutes 16:41:35 I have made the request to generate https://www.w3.org/2019/05/15-css-minutes.html trackbot 16:41:36 RRSAgent, bye 16:41:36 I see no action items