16:56:16 RRSAgent has joined #css 16:56:16 logging to https://www.w3.org/2019/11/13-css-irc 16:56:18 RRSAgent, make logs public 16:56:18 Zakim has joined #css 16:56:20 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:56:20 Date: 13 November 2019 16:56:24 present+ 16:56:45 present+ 16:56:49 ScribeNick: dael 16:57:49 jensimmons has joined #css 16:58:21 present+ 16:58:42 present+ 16:59:31 Rossen_: We'll get going in a couple minutes 16:59:43 present+ 17:00:16 present+ 17:00:25 present+ 17:00:44 tantek has joined #css 17:00:54 Rossen_: We'll do 2 minutes past the hour 17:01:09 present+ 17:01:19 present+ 17:01:23 Present+ 17:02:23 Rossen_: It's 2 minutes past, let's start 17:02:36 Rossen_: Wanted to call if there are extra agenda items or items to change 17:02:41 fantasai: Brief announcement 17:02:47 https://www.w3.org/wiki/Process2020 17:02:57 present+ 17:03:04 fantasai: We posted an explainer to process changes and edits at this wiki^ 17:03:23 https://lists.w3.org/Archives/Public/spec-prod/2019OctDec/0007.html 17:03:34 fantasai: If you have comments on improving, like the changes, dislike the changes, let me know about problems. If you have opinions forward them to spec-prod 17:03:44 present+ 17:03:45 teleject has joined #css 17:03:47 astearns: TabAtkins wanted first item to be postponed slightly on IRC 17:04:00 present+ 17:04:05 dholbert has joined #css 17:04:06 Rossen_: I see Chris will be a bit late for fonts 3 17:04:16 astearns: TabAtkins will be at least 15 minutes late 17:04:23 Topic: Switch advanced attr() to being var()-like 17:04:30 github: https://github.com/w3c/csswg-drafts/issues/4482 17:04:43 github: none 17:04:51 present+ 17:04:53 Topic: Resolved values of grid-template-rows/columns don't round-trip 17:05:04 Topic: publishing 17:05:10 Rossen_: Text level 3 17:05:16 florian: Text 4; fonts 3 17:05:33 fantasai: fonts 4 as well; fonts 3 is CR isn't it? 17:05:39 Rossen_: It is. 17:05:46 s/CR/REC/ ! :D 17:05:48 Rossen_: Let's do text L4 17:05:57 Rossen_: Is it editorial? 17:06:36 florian: Not only. At previous F2F we discussed word boundary in spaces, the text was added. It was announced and review requested. We're not getting to CR, but it's been in the ED for a while and it should go into an official space 17:06:49 florian: It's been a year since it was published. Sounds like good timing 17:06:57 leaverou_ has joined #css 17:07:04 aja has joined #css 17:07:14 Rossen_: And the edits are in? 17:07:32 bradk has joined #css 17:07:36 florian: They are. It's the things I talked about at last F2F. Maybe some editorial tweaks 17:07:44 Rossen_: Great. 17:07:51 RESOLVED: Publish new WD for Text 4 17:08:02 Rossen_: Fonts 4 should we wait for Chris? 17:08:11 fantasai: Chris is on IRC 17:08:17 fantasai: I think we publish since he requested 17:08:20 Please wait until later 17:08:27 Ok great 17:08:35 smfr has joined #css 17:08:41 AmeliaBR has joined #css 17:08:43 RESOLVED: Republish Fonts 4 17:08:49 present+ (irc only) 17:09:05 Yay 17:09:12 Topic: Subsetting grid-template-areas in subgrids 17:09:17 present+ 17:09:22 github: https://github.com/w3c/csswg-drafts/issues/4411 17:09:37 https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-548945615 17:09:46 present+ 17:09:46 fantasai: Summary comment^ 17:10:20 fantasai: Two proposals, make grid-template-areas a thing and exclude names from inheriting. Currently grid-templates make start and end and those would not inherit into subgrid 17:10:54 fantasai: Other option is we take those names and instead of saying don't inherit in, they do inherit in and if there's partial overlap we clip start or end so they exist in the grid and you can position to the overlap 17:11:42 fremy has joined #css 17:11:42 fantasai: Slight inconsitencies for both. If we exclude then a manually created grid area such as named lines as foo-start I implicitly create foo which I can position into. Kinda works on a subgrid; if both lines overlap. True in both cases 17:12:16 fantasai: Question is do we want...we didn't want to create inconsisent behavior for tempaltes. Want to say either set to part it overlaps or exclude all lines. Those are the two options. 17:12:22 fantasai: Would like to hear from other preference 17:12:27 Rossen_: Prefer second option. 17:12:33 A) Exclude parent template and its implicit line names from subgrid 17:12:44 B) Subset parent template to the part where it overlaps the subgrid, allowing it to be usable 17:12:48 Rossen_: Having the grid-template-area lines not available from subgrid is quite weird given that rows and columns are available 17:13:03 Rossen_: I would lean toward the second solution if we have to pick from these two 17:13:25 dbaron: Looks like Mats preference was first, but seems reasonably okay with either. Seems he had impl of 2nd and changed to 1st. 17:13:37 fantasai: He originally wanted B, then did A when we weren't sure 17:13:44 Rossen_: dbaron do you know why he switched? 17:14:22 rego: It was not impl in all cases. I had example in issue that was different in 2 cases where should be same. He didn't have whole impl. I think he did the simpliest thing 17:14:33 present+ 17:14:37 Mats's comments https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542292465 17:14:40 Rossen_: If we go with option B (the second option) 17:14:52 Rossen_: Would that be okay dbaron if you're representing Mats? 17:15:00 dbaron: I'm only reading his comments in issue 17:15:31 jensimmons: Still trying to wrap my head around. Seems like AmeliaBR and rachelandrew were advocating for A 17:15:41 Rossen_: A in TabAtkins summary is option 2 17:15:52 s/AmeliaBR/Miriam Suzanne/ 17:15:56 option 2 for me (don't think my mic is working) 17:16:34 fantasai: rego I think case with a difference is case of explicit line names creating implicit area. 17:16:40 abalasubramaniyan has joined #css 17:17:03 fantasai: TabAtkins and I discussed and concluded there wasn't a good way to make that work. Would require changes to how line names were handled. Couldn't figure out how to not cause changes to normal grid 17:17:38 fantasai: Concluded line names from tempate are special and special for subgrids but explicit line names don't. Which means you can handle hte partial overlap nicely for template areas, but not for area with explicit names 17:17:46 rego: So original impl from Mats is final? 17:18:23 fantasai: Yeah. Either way the line names created by template area need to be special so we either notice they're excluded or clamped for partial overlaps. Seems second is more useful 17:18:47 rego: Still don't like difference in the example. I understand it's useful so maybe it's good enough. I think the difference can create confusion. 17:19:00 fantasai: Ideally we would solve both, but didn't find a good way. 17:19:19 rego, see https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542288855 for problems with the other options 17:19:21 Rossen_: Not hearing strong opinions, but more people toward option 2 17:19:40 Rossen_: Objections to resolving on "Subset parent template to the part where it overlaps the subgrid, allowing it to be usable" unless there's additional comments 17:19:42 Example of option 2 - https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-543174237 17:20:00 Rossen_: Objections to Option 2: Subset parent template to the part where it overlaps the subgrid, allowing it to be usable ? 17:20:32 RESOLVED: Pick option 2 effectively subset the grid area into the subgrid 17:20:39 Topic: publication 17:21:00 fantasai: That's last subgrid so I'd like to propose every non-subgrid feature goes to L3 so we can go to CR 17:21:07 https://drafts.csswg.org/css-grid-2/#alignment 17:21:17 fantasai: There's a bunch that haven't been edited in. We'd defer this ^ 17:21:45 fantasai: THere's a handful where we resolved ot add features and I propose we start a new WD with those and put subgrid L2 to CR 17:21:46 +1 on CR for Grid L2 17:22:04 fantasai: We didn't edit them in because Grid 1 was a little unstable. But none of those features are as urgent as subgrid 17:22:32 +1 on CR for Grid L2 with only subgrid added 17:22:35 Rossen_: Proposal: Break Grid L2 down to only contain subgrid features. Take L2 to CR. Start L3 with all things moved 17:22:48 presumably L2 will have the L1 stuff too? 17:22:52 Resolved: Start L3 with all work that is in L2 but not about subgrid 17:23:01 dbaron, that was my assumption too 17:23:08 +1 Let's get going on Lvl 3 baby! All the ideas about how to make Grid better!!! 17:23:16 fantasai: Q for ChrisL. Grid 2 is a diff spec and doesn't have L1. There's a lot in Grid L1 that aren't posted to CR. 17:23:28 fantasai: I don't think I can copy it over yet. Is it okay to publish CR as a diff? 17:23:40 s/have/have L1 content/ 17:23:41 I'd be ok with CR as a diff 17:23:51 astearns: I'd wait until we have L1 done. CRs are meant for review and diff is hard to review 17:24:18 would rather than CR as a diff than have to wait until "L1 done" 17:24:20 fantasai: It's easier b/c it's one fairly isolated feature. We're adding this thing. I think it's okay as diff, but I want to fold in eventually 17:24:25 Agreed, delta specs are harder to review 17:24:32 florian: Another is publish subgrid L1 as a CR 17:24:42 fantasai: No, not making this another spec. 17:24:46 fantasai: I'll wait if we want. 17:24:48 agree with keeping this as grid L2 17:24:54 But okay if explicitly stated all of L1 will be included 17:25:04 fantasai: We're waiting on a handful of Grid L1, but we're hung up on not having tests 17:25:20 I get the feeling most people here are ok with L2 as a diff CR 17:25:21 florian: CR should be acceptable as REC and a diff isn't. We should wait 17:25:34 jensimmons: I wonder if there's people that love grid enough they'd write tests 17:25:44 fantasai: I think a lot are written and we need to figure out where they are 17:26:03 Rossen_: We can wait until next week. It would be nice to make progress 17:26:20 fantasai: If it's up to me to do tests I won't get to it until mid-Dec at least 17:26:32 I'd also be ok with L2 as another diff WD with explicit status stating we believe the additions are all CR-worthy, and that the only change expected before CR is the incorporation of all of L1 17:26:37 Rossen_: Let's get them in 2019 at least 17:27:02 Rossen_: Reading ChrisL in IRC that he's okay if explicitly stated all L1 included. I guess republish with a note? Not sure what that looks like for CR 17:27:08 florian: Not convinced process allows that 17:27:23 Rossen_: Objections ot moving grid L2 as CR? We'll figure out format but we can resolve to do it now 17:27:29 florian, wrong framing. Not convinced process disallows that :) 17:27:41 Rossen_: And from previous resolution it means Grid L2 is the delta of 1 and subgrid 17:27:44 Rossen_: Objections? 17:27:54 fantasai: Union of 1 + subgrid 17:28:03 RESOLVED: Publish Grid L2 as CR 17:28:15 Rossen_: We'll work with ChrisL to figure out exactly what it looks like 17:28:23 🎉 17:28:25 Rossen_: That's awesome because Grid is awesome 17:28:33 Topic: Switch advanced attr() to being var()-like 17:28:40 github: https://github.com/w3c/csswg-drafts/issues/4482 17:28:40 florian_ has joined #css 17:29:18 TabAtkins: Several years ago we defined the more complicated attr() functionality where it supplies the type. If you say foo=5px we parse as length. 17:29:23 TabAtkins: No one impl. I realized why. 17:30:04 TabAtkins: It ends up being high cost for low value. Type checking eagerly so at parse time we can reject it it means every thing that does grammar checking have to account for possibility of attr() being there 17:30:10 TabAtkins: Lots of fiddly detail work. 17:30:45 TabAtkins: We did it because we don't have valid at parse time but rejected later. We now have that for var(). The var() machinery and building on that gives us a lot of tools that didn't exist earlier which make attr() easier 17:31:04 🐈 17:31:29 TabAtkins: Precise details of grammar aren't laid out, but core is we make attr() act like var(). It makes poperty automatically valid at parse time and we do parse at computed time. We validate at that time. 17:32:15 TabAtkins: Specifying type lets you validate you put the right thing in the attr(). Handling attributes elsewhere tends to allow garbage and ignore. We maintain that and check type and make sure it works. 17:32:36 TabAtkins: If we base on var() it's the same functionality for authors and a significant decrease in implementation complexity. 17:32:52 TabAtkins: I'd like to persue this change and the impl wants to experiment in it 17:32:53 I strongly support this! 17:32:57 TabAtkins: Is WG ameniable? 17:33:31 emilio: I'm not opposed but concerned about type checking token string and then doing parsing again. When I looked at impl attr() I suggested doing it like variables in bugzilla. 17:33:54 emilio: Complexity of doing attr didn't seem so high either. I'm concerned about parsing, tokenization, and then parsing on performance. 17:34:03 emilio: Other concern is XSS but that happens either way 17:34:39 TabAtkins: Reason why I don't htink first bit is a concern is it ends up being identical to custom values and properties API. Ideal is it works that way but it's inline 17:35:00 emilio: I think that's also a concern with custom properties. I don't want to block on it, it's mostly theoretical 17:35:11 TabAtkins: Never say never but I doubt used in performance sensistive ways 17:35:30 AmeliaBR: My first concern would be how can we make it work logically with the existing use of the attribute function in the content property 17:36:19 AmeliaBR: You've been talking as distinguishing if an explicit type is set. More I'm thinking maybe not necessary. If you don't have an explicit type the type is assumed string and any attribute can be parsed as a string, returned in a string. So maybe not an issue b/c string is always valid in content 17:36:37 AmeliaBR: I'd like to see the exact write up and make sure it makes sense in backwards compat without special behavior 17:37:17 TabAtkins: Not possible w/o any backwards compat b/c assume valid at parse time. Content properties currently invaid but use attr() become valid at parse time. It is a behavior change if we make unspecified type attr() use this. 17:37:46 TabAtkins: Not sure what's best if we split parsing into separate function rather then flag it as attr() here. Puts you in 2 parsing modes based on detail of function grammar. 17:38:17 TabAtkins: If we think it's okay for behavior change in content where you wrote an invalid with a fallback and you're relying on that that seems minor. Otherwise good with your option. 17:38:29 TabAtkins: There's some possibilities there, we can experiment 17:39:04 AmeliaBR: Youre example of something suddenly valid is if something else in content property would be a parse error. Like using slash syntax with alternative text in a browser that doesn't support makes a difference if it's parse itme error 17:39:13 TabAtkins: Exactly. You'd no longer have the fallback 17:39:44 AmeliaBR: I would lean toward having a separate function for the type version and use attr() for how it's curerntly supported. Might be problematic for UA that support attr() more widely 17:40:02 TabAtkins: No idea if various printers support. I know no web browsers do. I'm not sure impl quality of whole thing 17:40:25 TabAtkins: But this is a behavior change. It will be off if there's a current impl. It's a custom thing or breaking change 17:40:51 TabAtkins: If no other questions just want to check for objections for me creating a full write up of changes. I can do that for review next week 17:41:03 Rossen_: Objections? 17:41:06 fantasai: Summary? 17:41:37 TabAtkins: There's a lot of possible ways how, but it's a change in validation to make it more var() like 17:41:57 TabAtkins: I'll have a write up fully next week. What's in the issue is the right jist 17:42:23 TabAtkins: It's switch attr() to var()-type validation rather than strict parse time validation 17:42:53 emilio: THe fallback might be able to be fix for attr(). Unfortunate to add new type of attr() that can't be detected. Nice if forced to a valid type. Worth thinking about 17:42:55 TabAtkins: Yep. 17:43:16 Rossen_: Objections to the approach of switch attr() to var()-type validation rather than strict parse time validation 17:43:19 +1 to try this out 17:43:27 fantasai: Not sure, but let him write it up 17:43:43 Rossen_: TabAtkins there's no objections. Go ahead and write it up and we'll look when you're ready 17:43:52 cat: meow 17:44:14 Topic: Resolved values of grid-template-rows/columns don't round-trip 17:44:24 github: https://github.com/w3c/csswg-drafts/issues/4475 17:44:39 See https://github.com/w3c/csswg-drafts/issues/4475#issuecomment-548908448 17:45:16 TabAtkins: Looks like reminant, as spec grid-template-row/column when you asked for resolved value you get width of implicit tracks as well as explicit. Given you can't spec implicit tracks this doesn't make any sense at all. 17:45:48 TabAtkins: Getting the width of implicit tracks is worthwhile. Functionality is reasonable, but a number of useful grid things it would be great to get from layout that aren't in properties right now. 17:45:58 TabAtkins: IN past proposed things that would require new grid API to get 17:46:09 TabAtkins: Resolved value of grid-templates does not round trip. 17:46:38 TabAtkins: Options; 1) leave as is. Resolved value is not a valid value and confusing because unless you know number of implicit rows you don't know where explicit starts 17:46:58 TabAtkins: 2) Change to only reflect explicit rows on resolved values. implicit we leave for a more explicit API 17:47:29 chris has joined #css 17:47:44 TabAtkins: 3) continue to allow grid-template-rows to express implicit but change grammar so it's valid. There is some value b/c only explicit are used for auto positioning by default. Being able to give bounds to auto while sizing outside could be worthwhile 17:48:04 TabAtkins: Would need to be able to spec when the explicit grid starts and stops which would also need to return in the resolved value 17:48:33 TabAtkins: We leave as is, change return of gCS for this so that it allows roundtripping either way 17:48:49 TabAtkins: Need to decide, this was an accident. If we leave as is need to be more explicit 17:49:07 TabAtkins: I prefer changing to be just explicit tracks. I could accept any of the 3. 17:49:25 fantasai: web compat is a substantial concern. Might be stuck with #1 17:49:34 emilio: Also [missed] 17:49:44 drousso has joined #css 17:50:06 s/[missed]/I also prefer 2 if we can get away with the compat issue/ 17:50:12 TabAtkins: Web compat is alwyas a concern and we might be struck with 1. Between 2 and 3 is group okay if we try for 2 and revert if web compat proves otherwise? 17:51:00 oriol: In issue I propose feature which allows define where grid line could be. It could place it in another place. I think something like this could have its own uses outside this issue. However I agree this prob needs more thought and be in something like Grid 3. 17:51:17 oriol: If we want to fix roundtripping we need mroe urgent for L1 so it's reasonable to try and remove implicit tracks 17:52:09 TabAtkins: Youre suggestion was option 3, but as you say requires additional work. How it interacts is unclear right now and a breaking change anywya. If breaking, might as well do one that's easier to work with. If we ever want explicit/implicit we can do that later 17:52:39 TabAtkins: Any strong preference for keeping current behavior? Or is everyone okay with trying to change gCS and falling back to no change if there's web compat problems? 17:52:43 please make it round-trip correctly :-) 17:52:47 I like the proposal 17:52:47 Rossen_: Try it out. It makes sense. 17:52:55 fantasai: We don't have syntax for that right? 17:53:32 TabAtkins: Not for 3. No one is suggesting widen the grammar first. This is keep as is and have gCS report explicit only or have gCS report more accurately 17:53:32 sorry, I was confused 17:53:57 Rossen_: Resolution would be for give the 2nd option a chance and see if there are compat reasons to instead keep current 17:54:05 Rossen_: Other opinions or objections? 17:54:36 emilio: No obj but I want to makes ure both Geck oa nd Chromium...info from gCS is not useful. Both Chromium and FF have special dev tools b/c gCS is not enough. 17:54:47 Rossen_: We can look at extending OM for grid 17:54:47 s/make sure/ note 17:55:01 Rossen_: I think you're pointing out more general issue. I don't disagree 17:55:02 https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl, fwiw 17:55:28 TabAtkins: Point is valid in that what's currently returned is not enough for current use cases. So w're not losing anything and we should look into more advanced on 17:55:31 Rossen_: agreed 17:55:37 Rossen_: Objectins? 17:55:53 RESOLVED: Give the 2nd option a chance and see if there are compat reasons to instead keep current behavior 17:55:53 innovati has joined #css 17:56:20 Topic: Spaces in grid-template-areas serialization 17:56:27 github: https://github.com/w3c/csswg-drafts/issues/4335 17:56:28 https://github.com/w3c/csswg-drafts/issues/4335 17:56:40 emilio, I'd love to with with you and jensimmons or anyone interested in this to figure out what devtools is using and how we could expose that to users. 17:56:50 fantasai: Want to clarify how spaces are handled. There's not compat. We said serialize between tokens we do a single space no matter if it's needed 17:56:59 fantasai: Want to confirm with WG 17:57:11 astearns: Makes sense to me 17:57:23 emilio: Seems weird to change string b/c we don't change string in other places 17:57:48 TabAtkins: You do change the string somewhat. Youd on't if parsing splits tokens correctly. But you trim spaces at end and collapse many to one 17:58:19 oriol: In issue #3261 we resolved against preserving percise string in favor of normalizing. Just wasn't clear on what to do with spaces 17:58:21 TabAtkins: Thanks 17:58:34 astearns: emilio? 17:58:38 emilio: No objections 17:58:45 TabAtkins: fwiw, this is the API exposed to devtools: https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl, via https://searchfox.org/mozilla-central/source/dom/webidl/Element.webidl#322 17:58:47 astearns: Other concerns? 17:59:02 Karen has joined #css 17:59:11 astearns: fantasai has comment at end with proposal 17:59:30 astearns: Objections to this? 17:59:47 RESOLVED: Specify serialization as proposed in https://github.com/w3c/csswg-drafts/issues/4335#issuecomment-548962309 17:59:50 topic: end 18:05:26 trackbot, end meeting 18:05:26 Zakim, list attendees 18:05:26 As of this point the attendees have been Rossen_, dael, dauwhe, cbiesinger, rachelandrew, astearns, florian, jensimmons, oriol, dbaron, fantasai, tantek, rego, teleject, plinss, 18:05:29 ... (irc, only), AmeliaBR, ChrisL, hober, chris 18:05:30 dholbert has joined #css 18:05:34 RRSAgent, please draft minutes 18:05:34 I have made the request to generate https://www.w3.org/2019/11/13-css-minutes.html trackbot 18:05:35 RRSAgent, bye 18:05:35 I see no action items