- From: Dael Jackson <[email protected]>
- Date: Wed, 13 Nov 2019 18:29:14 -0500
- To: [email protected]
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Text L4 ----------- - RESOLVED: Publish new WD for Text 4 CSS Fonts L4 ------------ - RESOLVED: Republish Fonts 4 Grid L2 ------- - RESOLVED: Pick option 2; effectively subset the grid area into the subgrid (Issue #4411: Subsetting grid-template-areas in subgrids) - RESOLVED: Start L3 with all work that is in L2 but not about subgrid - RESOLVED: Publish Grid L2 as CR CSS Values 4 ------------ - The group was interested in seeing specific details for changing attr() to be more var()-like (Issue #4482: Switch advanced attr() to being var()-like) so TabAtkins will write up spec text for review. CSS Grid 1 ---------- - RESOLVED: Give the 2nd option a chance and see if there are compat reasons to instead keep current behavior (Issue #4475: Resolved values of grid-template-rows/columns don't round-trip) - TabAtkins will look into what the Gecko and Chromium devtools expose about grid to see if something similar can be specified as a future enhancement. - RESOLVED: Specify serialization as proposed in https://github.com/w3c/csswg-drafts/issues/4335#issuecomment-548962309 [When serializing either the specified or computed value of a <<string>> value of 'grid-template-areas', each null cell token is serialized as a single "." (U+002E FULL STOP), and consecutive cell tokens are separated by a single space (U+0020 SPACE), with all other white space elided.] ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2019Nov/0005.html Present: Rachel Andrew Rossen Atanassov David Baron Amelia Bellamy-Royds Christian Biesinger Oriol Brufau Tantek Çelik Dave Cramer Elika Etemad Simon Fraser (IRC only) Dael Jackson Chris Lilley Peter Linss Theresa O'Connor Manuel Rego Casasnovas Florian Rivoal Christopher Schmitt Jen Simmons Alan Stearns Scribe: dael Rossen: It's 2 minutes past, let's start Rossen: Wanted to call if there are extra agenda items or items to change fantasai: Brief announcement <fantasai> https://www.w3.org/wiki/Process2020 fantasai: We posted an explainer to process changes and edits at this wiki^ <fantasai> https://lists.w3.org/Archives/Public/spec-prod/2019OctDec/0007.html 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 <tantek> quick summary, Process2020 explainer is looking quite good. Only nit is I don't think the Registries piece is mature enough as compared to the rest. I'd advise splitting that out and giving it more time to iterate/develop, perhaps for 2021. <tantek> everything else I'm looking forward to reviewing closely (actual process doc changes), and quite optimistic about. :) astearns: TabAtkins wanted first item to be postponed slightly on IRC Rossen: I see Chris will be a bit late for fonts 3 astearns: TabAtkins will be at least 15 minutes late Publications ============ Rossen: Text level 3 florian: Text 4; fonts 3 fantasai: fonts 4 as well; fonts 3 is REC isn't it? Rossen: It is. Rossen: Let's do text L4 Text Level 4 ------------ Rossen: Is it editorial? 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 florian: It's been a year since it was published. Sounds like good timing Rossen: And the edits are in? florian: They are. It's the things I talked about at last F2F. Maybe some editorial tweaks Rossen: Great. RESOLVED: Publish new WD for Text 4 Fonts Level 4 ------------- Rossen: Fonts 4 should we wait for Chris? fantasai: Chris is on IRC <ChrisL> Please wait until later fantasai: I think we publish since he requested <ChrisL> Ok great RESOLVED: Republish Fonts 4 Grid L2 ======= Subsetting grid-template-areas in subgrids ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4411 <fantasai> https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-548945615 fantasai: Summary comment^ 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 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 fantasai: Slight inconsistencies 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 fantasai: Question is do we want...we didn't want to create inconsistent behavior for templates. Want to say either set to part it overlaps or exclude all lines. Those are the two options. fantasai: Would like to hear from other preference <fantasai> A) Exclude parent template and its implicit line names from subgrid <fantasai> B) Subset parent template to the part where it overlaps the subgrid, allowing it to be usable Rossen: Prefer second option. Rossen: Having the grid-template-area lines not available from subgrid is quite weird given that rows and columns are available Rossen: I would lean toward the second solution if we have to pick from these two dbaron: Looks like Mats preference was first, but seems reasonably okay with either. Seems he had impl of 2nd and changed to 1st. fantasai: He originally wanted B, then did A when we weren't sure Rossen: dbaron do you know why he switched? 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 simplest thing <fantasai> Mats's comments https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542292465 Rossen: If we go with option B (the second option) Rossen: Would that be okay dbaron if you're representing Mats? dbaron: I'm only reading his comments in issue jensimmons: Still trying to wrap my head around. Seems like Miriam Suzanne and rachelandrew were advocating for A Rossen: A in TabAtkins summary is option 2 <rachelandrew> option 2 for me (don't think my mic is working) fantasai: rego I think case with a difference is case of explicit line names creating implicit area. 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 fantasai: Concluded line names from template are special and special for subgrids but explicit line names don't. Which means you can handle the partial overlap nicely for template areas, but not for area with explicit names rego: So original impl from Mats is final? 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 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. fantasai: Ideally we would solve both, but didn't find a good way. <fantasai> rego, see https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542288855 for problems with the other options Rossen: Not hearing strong opinions, but more people toward option 2 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 <fantasai> Example of option 2 - https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-543174237 Rossen: Objections to Option 2: Subset parent template to the part where it overlaps the subgrid, allowing it to be usable? RESOLVED: Pick option 2 effectively subset the grid area into the subgrid Publication ----------- fantasai: That's last subgrid so I'd like to propose every non-subgrid feature goes to L3 so we can go to CR <fantasai> https://drafts.csswg.org/css-grid-2/#alignment fantasai: There's a bunch that haven't been edited in. We'd defer this ^ fantasai: There's a handful where we resolved to add features and I propose we start a new WD with those and put subgrid L2 to CR fantasai: We didn't edit them in because Grid 1 was a little unstable. But none of those features are as urgent as subgrid <ChrisL> +1 on CR for Grid L2 <tantek> +1 on CR for Grid L2 with only subgrid added Rossen: Proposal: Break Grid L2 down to only contain subgrid features. Take L2 to CR. Start L3 with all things moved <dbaron> presumably L2 will have the L1 stuff too? <tantek> dbaron, that was my assumption too <jensimmons> +1 Let's get going on Lvl 3 baby! All the ideas about how to make Grid better!!! RESOLVED: Start L3 with all work that is in L2 but not about subgrid fantasai: Question for ChrisL. Grid 2 is a diff spec and doesn't have L1 content. There's a lot in Grid L1 that aren't posted to CR. fantasai: I don't think I can copy it over yet. Is it okay to publish CR as a diff? <tantek> I'd be ok with CR as a diff <tantek> would rather than CR as a diff than have to wait until "L1 done" astearns: I'd wait until we have L1 done. CRs are meant for review and diff is hard to review <ChrisL> Agreed, delta specs are harder to review fantasai: It's easier because 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 florian: Another is publish subgrid L1 as a CR fantasai: No, not making this another spec. fantasai: I'll wait if we want. <tantek> agree with keeping this as grid L2 <ChrisL> But okay if explicitly stated all of L1 will be included <tantek> I get the feeling most people here are ok with L2 as a diff CR fantasai: We're waiting on a handful of Grid L1, but we're hung up on not having tests florian: CR should be acceptable as REC and a diff isn't. We should wait jensimmons: I wonder if there's people that love grid enough they'd write tests fantasai: I think a lot are written and we need to figure out where they are Rossen: We can wait until next week. It would be nice to make progress fantasai: If it's up to me to do tests I won't get to it until mid-Dec at least Rossen: Let's get them in 2019 at least <tantek> 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 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 florian: Not convinced process allows that Rossen: Objections to moving grid L2 as CR? We'll figure out format but we can resolve to do it now Rossen: And from previous resolution it means Grid L2 is the delta of 1 and subgrid Rossen: Objections? fantasai: Union of 1 + subgrid RESOLVED: Publish Grid L2 as CR Rossen: We'll work with ChrisL to figure out exactly what it looks like <tantek> 🎉 Rossen: That's awesome because Grid is awesome CSS Values 4 ============ Switch advanced attr() to being var()-like ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4482 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. TabAtkins: No one impl. I realized why. 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 TabAtkins: Lots of fiddly detail work. 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 TabAtkins: Precise details of grammar aren't laid out, but core is we make attr() act like var(). It makes property automatically valid at parse time and we do parse at computed time. We validate at that time. 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. TabAtkins: If we base on var() it's the same functionality for authors and a significant decrease in implementation complexity. TabAtkins: I'd like to pursue this change and the impl wants to experiment in it TabAtkins: Is WG amenable? <fremy> I strongly support this! 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. emilio: Complexity of doing attr() didn't seem so high either. I'm concerned about parsing, tokenization, and then parsing on performance. emilio: Other concern is XSS but that happens either way TabAtkins: Reason why I don't think 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 emilio: I think that's also a concern with custom properties. I don't want to block on it, it's mostly theoretical TabAtkins: Never say never but I doubt used in performance sensitive ways 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 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 because string is always valid in content AmeliaBR: I'd like to see the exact write up and make sure it makes sense in backwards compat without special behavior TabAtkins: Not possible w/o any backwards compat because assume valid at parse time. Content properties currently invalid but use attr() become valid at parse time. It is a behavior change if we make unspecified type attr() use this. 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. 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. TabAtkins: There's some possibilities there, we can experiment AmeliaBR: Your 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 time error TabAtkins: Exactly. You'd no longer have the fallback AmeliaBR: I would lean toward having a separate function for the type version and use attr() for how it's currently supported. Might be problematic for UA that support attr() more widely TabAtkins: No idea if various printers support. I know no web browsers do. I'm not sure impl quality of whole thing 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 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 Rossen: Objections? fantasai: Summary? TabAtkins: There's a lot of possible ways how, but it's a change in validation to make it more var() like TabAtkins: I'll have a write up fully next week. What's in the issue is the right gist TabAtkins: It's switch attr() to var()-type validation rather than strict parse time validation 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 TabAtkins: Yep. Rossen: Objections to the approach of switch attr() to var()-type validation rather than strict parse time validation <astearns> +1 to try this out fantasai: Not sure, but let him write it up Rossen: TabAtkins there's no objections. Go ahead and write it up and we'll look when you're ready CSS Grid 1 ========== Resolved values of grid-template-rows/columns don't round-trip -------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4475 <fantasai> See https://github.com/w3c/csswg-drafts/issues/4475#issuecomment-548908448 TabAtkins: 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. 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. TabAtkins: In past proposed things that would require new grid API to get TabAtkins: Resolved value of grid-templates does not round trip. 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 TabAtkins: 2) Change to only reflect explicit rows on resolved values. implicit we leave for a more explicit API TabAtkins: 3) Continue to allow grid-template-rows to express implicit but change grammar so it's valid. There is some value because only explicit are used for auto positioning by default. Being able to give bounds to auto while sizing outside could be worthwhile 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 TabAtkins: We leave as is, change return of gCS for this so that it allows round-tripping either way TabAtkins: Need to decide, this was an accident. If we leave as is need to be more explicit TabAtkins: I prefer changing to be just explicit tracks. I could accept any of the 3. fantasai: Web compat is a substantial concern. Might be stuck with #1 emilio: Also I also prefer 2 if we can get away with the compat issue TabAtkins: Web compat is always a concern and we might be stuck with 1. Between 2 and 3 is group okay if we try for 2 and revert if web compat proves otherwise? 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 probably needs more thought and be in something like Grid 3. oriol: If we want to fix round-tripping we need more urgent for L1 so it's reasonable to try and remove implicit tracks TabAtkins: Your suggestion was option 3, but as you say requires additional work. How it interacts is unclear right now and a breaking change anyway. If breaking, might as well do one that's easier to work with. If we ever want explicit/implicit we can do that later 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? <dbaron> please make it round-trip correctly :-) <florian> I like the proposal Rossen: Try it out. It makes sense. fantasai: We don't have syntax for that right? 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 <fantasai> sorry, I was confused Rossen: Resolution would be for give the 2nd option a chance and see if there are compat reasons to instead keep current Rossen: Other opinions or objections? emilio: No objections but I want note sure both Gecko and Chromium...info from gCS is not useful. Both Chromium and FF have special dev tools because gCS is not enough. Rossen: We can look at extending OM for grid Rossen: I think you're pointing out more general issue. I don't disagree <emilio> https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl fwiw TabAtkins: Point is valid in that what's currently returned is not enough for current use cases. So we're not losing anything and we should look into more advanced on Rossen: Agreed Rossen: Objections? RESOLVED: Give the 2nd option a chance and see if there are compat reasons to instead keep current behavior <TabAtkins> 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. <emilio> 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 Spaces in grid-template-areas serialization ------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4335 fantasai: Want to clarify how spaces are handled. There's no compatibility. We said serialize between tokens we do a single space no matter if it's needed fantasai: Want to confirm with WG astearns: Makes sense to me emilio: Seems weird to change string because we don't change string in other places TabAtkins: You do change the string somewhat. You don't if parsing splits tokens correctly. But you trim spaces at end and collapse many to one oriol: In issue #3261 we resolved against preserving precise string in favor of normalizing. Just wasn't clear on what to do with spaces TabAtkins: Thanks astearns: emilio? emilio: No objections astearns: Other concerns? astearns: fantasai has comment at end with proposal astearns: Objections to this? RESOLVED: Specify serialization as proposed in https://github.com/w3c/csswg-drafts/issues/4335#issuecomment-548962309
Received on Wednesday, 13 November 2019 23:29:46 UTC