Brief   Full   Jump  


High contrast


[CSSWG] Minutes Telecon 2017-03-15 [css-grid] [css-inline]

1 message.

[CSSWG] Minutes Telecon 2017-03-15 [css-grid] [css-inline]
Dael Jackson   Wed, 15 Mar 2017 20:43:45 -0400

www-style > March 2017 > 0060.html

Received on Thursday, 16 March 2017 00:44:50 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to:

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Grid DoC -------- - Issue #1: minmax max value ( - The group agreed that the use case was valid, but that it should be solved in a different way then the proposal so that the standard min/max priority can be maintained. - RESOLVED: Reject this issue for L1 of grid. - Issue #8: dominant-baseline should apply to grid/flex containers ( - RESOLVED: Accept text - Issue #16: Defer subgrid ( - TabAtkins & fantasai proposed to not defer as there wasn't a solid counter proposal. - As the group discussed the proposal, it developed that there was a desire to get subgrid right since no implementor had yet implemented the partial proposal that was originally placed in Grid in order to encourage implementation. - RESOLVED: Move subgrid to level 2 of Grid - Issue #17: Is fr a length? ( - RESOLVED: length & frs are not combinable, but will reconsider if/when length & auto are combinable - RESOLVED: Republish Grid Driving specs to REC -------------------- - Rossen introduced the group to the plan he and astearns developed to help the group move specs towards REC. - At the beginning of each call there will be a status check for all specs that are in CR or are stable WD to see what steps have been taken to move them to REC and give authors the opportunity to request assistance. - This new process will begin on either the 22 or 29 March calls, depending on progress agreeing upon the beginning list of specs to prioritize. ===== FULL MINUTES BELOW ====== Agenda: Present: Rachel Andrew Rossen Atanassov Tab Atkins David Baron Tantek Çelik Alex Critchfield Benjamin De Cock Elika Etemad Daniel Glazman Tony Graham Dael Jackson Brad Kemper Chris Lilley Peter Linss Myles Maxfield Anton Prowse Melanie Richards Geoffrey Sneddon Alan Stearns Greg Whitworth (IRC only) Steve Zilles Regrets: Bert Bos Dave Cramer Simon Fraser Vladamir Levantovsky Michael Miller Jen Simmons Scribe: dael Rossen: Let's start. Rossen: As usual, any extra agenda items? <gsnedders> I want to mention <> wrt merging the test repos. gsnedders: I want to mention this ^ email. fantasai: I'd like to go over the flexbox status. fantasai: Anything we can do to get it republished soon-ish. Rossen: Perhaps that will be covered in agenda #5. Rossen: If we don't cover it then we'll put it separately. Rossen: Anything else I might have missed? Rossen: I'm only hearing gsnedders addition Grid DoC ======== <fantasai> minmax max value (Issue #1) --------------------------- <fantasai> <fantasai> fantasai: First open issue is #1 which is about...we got a message from Ollie Williams explaining a case when you have conflicting min and max constraints the min wins generally, but this is a case where max should win. fantasai: We closed as no change for consistency, but his use case is valid and it would make more sense if it's possible to express this sizing constraint where the this use case the optimal was 20% and the max was 250px and that wasn't working out. fantasai: This is a totally valid use case, it would be nice to have a syntax to express it. Maybe fore next grid release or something. <fantasai> grid-template-columns: 1fr repeat(4, minmax(20%, 250px)) 1fr fantasai: Here's the example^ fantasai: [explains example] fantasai: Perfectly reasonable. We can't solve other than nest the grid in a larger container. fantasai: Proposal is we reject the proposal, but also request that if the WG has a reasonable way to express this raise an issue so we can add this. Rossen: Comments? rachelandrew: It's not a use case that's come up from anyone else and I've heard lots this week. It feels like there will be lots of little things like this. I feel we're going to get an awful lot of this kind of use case as people get their hands on grid. Rossen: I would agree with rachelandrew and fantasai. Pushing this to a different level or in the sizing spec is the path forward. Having it punted from L1 grid sounds right. Rossen: If there are no other thoughts we can call for resolution Rossen: Objections to reject this issue for L1 of grid? fantasai: We want to solve the use case, but perhaps in a slightly different way. Rossen: We can work it out, but not in grid L1. fantasai: In L2 we won't invert the order of priority for min/max. We'd solve the use case in another way. Rossen: For sure. I'm just saying let's cross this bridge when we come to it. <fantasai> And I'm saying we're not crossing any bridges that invert the order of minmax priority RESOLVED: Reject this issue for L1 of grid. dominant-baseline should apply to grid/flex containers (Issue #8) ----------------------------------------------------------------- <fantasai> <fantasai> fantasai: It's a CSS inline layout issue. Max was pointing out that the 'applies to' section doesn't say it applies to grid & flexbox and it should. I made the change to inline but want the WG to say okay. fantasai: Change was to CSS Inline. <fantasai> fantasai: There's a dominant baseline prop. Link ^ Rossen: Any feedback? Rossen: Other opinions? Rossen: Anyone feel we shouldn't apply dominant baseline to grid and flex containers? fantasai: Also applied alignment-baseline to flex/grid items RESOLVED: Accept text <dbaron> I find it a bit curious that baseline-shift applies to fewer elements than alignment-baseline and dominant-baseline. <fantasai> dbaron, that's a fair point :) I guess there's no reason it couldn't apply to baseline alignment in general... ACTION: fantasai extend applies to for baseline-shift to match alignment-baseline <trackbot> Created ACTION-836 Defer subgrid (Issue #16) ------------------------- <fantasai> <fantasai> fantasai: He's asking to drop subgrid because he wants to see if you can implement subgrid independently to each axis. TabAtkins and I said if you want something you want changed and that destabilizes the spec we'll drop it, but so far you've just said I'm not sure about the spec. That's our position, but we wanted to know the WGs thoughts. Rossen: So your opinion is not change the current spec and wait for a counter proposal that negates or improves the current solution? fantasai: Yes. tantek: Is anyone else impl subgrid? Rossen: FF is. tantek: Which is Mats who raised the issue. [issue author clarification] rachelandrew: I've commented on the thread. I'd love to see Mats...I've written my concerns about locked to axis and I'd love to see Mats investigation on if it's possible to do it more like the original. It would be a shame if he doesn't get to do that. I'm concerned about how useful the spec will be. I don't want him to feel the investigation would not be useful. TabAtkins: No one is holding up Mats but himself. He thinks we're not open to changing and we are. fantasai: Maybe he wants us to pull so no one else implements until there's investigation? Rossen: We certainly welcome the feedback. If Mats is under a different opinion I'd love to have him join a call or meeting to make sure he feels supported. If he has any impl experience and feedback with the current proposal we'd love to hear it. This is why we have CRs and call for impl feedback. Rossen: In the lack of concrete proposal given the work that's gone in already to subgrid and the feedback we have gotten I don't believe there's enough merit to remove it and say we'll have something better, trust us. * tantek wonders if Rossen is speaking with chair hat or MSFT hat now Rossen: Also, we've made significant efforts to make the symmetry of grid in respect to rows and columns and it would be unfortunate if we spec subgrid to favor one or the other. Rossen: And I was speaking as a chair. I'll say if I'm using my MSFT hat. * fantasai doesn't have any objection to whichever way we go. tantek: To see if I can communicate impressions from Mats, I think TabAtkins's characterization is true, but when there's a spec in CR it indicates a very specific direction and there's no indication in the spec text other directions are possible and does communicate strongly by its state. It's reasonable for Mats to feel that way. I think anyone outside the WG would have a similar impression. tantek: Mats as far as I can tell is the impl that's most ahead on this work and the subgrid is calling for impl feedback. I think we shouldn't just prefer...even vague implementor feedback trumps aspirational precision. I'm not asking to replace the current spec, but it's reasonable to indicate with spec text that there's an alternative being investigated. tantek: That's useful to show Mats his work is valuable and communicate to other impl that this is useful to the WG and welcome. And say that we are looking for alternatives here. tantek: That's my proposal, but of course we're in CR which brings up should we drop. <rachelandrew> +1 to tantek's proposal TabAtkins: There's no alternate proposal. It's just vaguely we should go back to thinking about independent axes. I recall when the original subgrid came up I wanted to push another level. It was author and dev concerns that made us look at a simplified version for this draft. If the group now feels it's more important to get it right and push it, that's fine. That's my original position. <Rossen> +1 to all of what TabAtkins said tantek: That's fair. There is a bit of...we are learning more about this conceptual space as we implement. There is new info, like we just heard from rachelandrew where there is now openness to biasing toward a correct version later. tantek: The specific proposal would be that we either separate it out or add at least an informative paragraph saying we're considering an alternative design that's independent on each axis. I agree it's vague but something that communicates it's happening. I think you'll see more specific proposals follow up. TabAtkins: Mats isn't just a third policy. We can tell him please work on this. We can point him to the minutes and communicate. tantek: That's part 1, but part 2 is to more implementers broadly. TabAtkins: Igalia monitors the issues list for grid. fantasai: Yes, Igalia & Mats follow minutes, but it's our job to be clear to everyone, including those that only read docs. If there's something important to tell implementors it should be in the doc. fantasai: Given the current state, we're shipping grid with everything except subgrid. Given that I don't object to putting that in L2 and doing that as a WD for comments. fantasai: I think Mats wanting to investigate is fantastic. We didn't do it because Igalia thought it was impossible. It would be great if they could talk and agree it's possible. TabAtkins: I agree which is why this needs to start in an issue with a proposal. I know how hard it was to think about originally. <fantasai> I don't think it was that hard to think about. <tantek> I'd like to hear rachelandrew's opinion on moving subgrid to a separate spec and spinning that up <tantek> at this point would anyone strongly object to moving subgrid to a separate spec? <tantek> / level <fantasai> I would object to moving it to moving it to a different module, yes :) Not to a different level. Rossen: As an impl or as a chair, I don't have a strong objection to moving subgrid out into a different spec or keeping it in spec with an explicit sentence that welcomes additional contributions. I also don't see how this is any different then any work in other specs. They are there to invite implementation and through this implementor feedback get specs that are more technically sounds as well as from user PoV. Rossen: If the only thing we're considering is an implementor that feels unheard, please invite Mats to join us so he feels all his ideas/objections/proposals have been heard. tantek: I can follow up with Mats directly. Rossen: In addition to the +1 to TabAtkins I also believe grid would have been done earlier if we didn't have spin cycles for subgrid. Rossen: Based on the implementation we had with grid when the initial proposal came through we know subgrid would be difficult. But there was no objections to pursuing that simple version. There hasn't been another version that came through. Rossen: Here we are discussing this again so it would be good to take an option so we can push forward on REC track for grid. fantasai: In terms of cycles we spent on subgrid, we spent more time talking about if it should be there or not instead of technical. Also as an editor I spent a minuscule amount of time on subgrid vs. the rest. Rossen: Agreed. Rossen: Do we want to keep subgrid in the grid spec or move it out on its own so it can signal additional and stronger request for feedback & changes? TabAtkins: I think we should only move things that are unstable and not ready for this level. * fantasai suggests a straw poll so we can move on <astearns> +1 to moving to the next level, for stability reasons <ChrisL> It sounds like it is less developed than the rest of grid. <ChrisL> so, push to next level <tantek> ChrisL - it is, less implemented by far (like none vs 3) <fantasai> ChrisL, I'm not sure that it's less stable, it just has received less attention because it hasn't been implemented yet Rossen: Okay. We have 3 implementation and none have subgrid. I think this speaks volumes. rachelandrew: I think move. rachelandrew: I really wanted it to be implemented and at the time Igalia had the revision there was hope there would be implementations. If we're talking changes it's better to move so that we say we're not expecting impl. And it tells authors we want more feedback. We can say we moved it so we can talk about what we need. <tantek> +1 rachelandrew Rossen: Let's try and have a resolution. Objections to moving subgrid to its own module? <astearns> next level of grid, not it's own fantasai: I do. I don't want another module. We can move to grid 2. <tantek> I'm fine with level 2 <gsnedders> I'm +1 on what fantasai said <ChrisL> agree with fantasai rachelandrew: Yes, I meant a level 2. Not a separate subgrid weird thing. <ChrisL> +1 to grid l2 Rossen: Okay, grid level 2. Objections to moving subgrid to level 2 of grid? RESOLVED: Move subgrid to level 2 of Grid Rossen: And again, tantek please reach out to Mats and make sure he feels he's being heard and supported here. TabAtkins: Can we please get Mats to join the WG? Rossen: Is he not? TabAtkins: I don't think officially. He doesn't have GitHub access. <fantasai> We should have all the Igalia and Mozilla devs who participate in GitHub to have edit privileges in the repo Rossen: So tantek you can follow up on that too. tantek: I can ask if he wants to officially join. I'll do my best to facilitate the communication. I can't force him to join. Is fr a length? (Issue #17) --------------------------- fantasai: I'm skipping issue #15. I have #17- a question about if fr are a length. <fantasai> fantasai: We said no, but it raised if they should be combinable in calc. fantasai: I wanted to get a resolution and see if there's interest in adding that fantasai: to a future level. TabAtkins: fr isn't a length: it's length adjacent but you can't combine it with lengths. Rossen: I would further that that I always thought of fr like auto for purposes of distributing space. For that reason we don't consider auto as combinable. fantasai: Yet. It's been requested. TabAtkins: And when we deal with that we can reconsider. As of now I think we should just resolve. fantasai: fr are not and will not be combinable with length and percentage values. Reconsider when auto values are combinable. <fantasai> proposed resolution: length & frs are not combinable, but will reconsider if/when length & auto are combinable Rossen: Sounds good. Rossen: Objections? RESOLVED: length & frs are not combinable, but will reconsider if/ when length & auto are combinable Republish --------- fantasai: Closing today's issues, we have one open which is 15 and we should just do an update officially. Rossen: I'm in favor. Rossen: Objections? RESOLVED: Republish Grid ChrisL: Updated CR? fantasai: Yes. <tantek> are we going to note imminent separation of moving of subgrid to level 2? <tantek> in this new Grid CR? <tantek> can we at least make a note of that happening soon since we have a resolution? <fantasai> fantasai: And Rego wanted to confirm the behavior we got for the replaced elements in grid is actually what we want. Anyone with an opinion please look at his comments (link above). If you think it's wrong, post an issue. Otherwise we'll assume it's closed. fremy if you could look it would be appreciated. tantek: Quick question on grid CR. Can we include a note about the move? ChrisL: I assumed the republish would include the removal. tantek: Great. That's awesome too. Thanks. Driving specs to REC ==================== <tantek> driving specs to REC ++ Rossen: I've had multiple discussions with people from W3M, AC members, etc. They always ask me why are we not publishing more REC. <fantasai> because we need more people like gsnedders <fantasai> companies send product managers here, but not super-awesome QA personnel Rossen: That started a little investigative process on how to move things forward. Are there things to expedite this. Rossen: We've had discussions with astearns and here's our proposal: Rossen: If we look through all the agendas that we've had this year alone we had discussions around almost everything being worked on [lists ever spec discussed this year] Rossen: Usually when we have time for discussion we're good at filling our call time. However, not every topic helps us move to REC. They don't come on spec work alone. We need tests. Rossen: Looking through the current specs, the ones that seem closest to driving to REC are...Writing Modes is the closest and we're waiting on final test reports. Rossen: Text level 3, fonts 3, cascade 3, transforms L1, flexbox, variables. Rossen: As a P2 we have grid as the first. The rest are open to discussion. Rossen: So how do we move forward? This is stating the obvious, I think. Rossen: So how do we make progress? <tantek> YES <tantek> this is kinda what I was trying to do at the Lisbon f2f <tantek> with what specs are going to CR by end of the year <tantek> etc. <tantek> Rossen++ Rossen: Our proposal is to dedicate all those specs as the first item for every call until they become RESs. We've discussed this in the past and usually the first objections was "if there's nothing to discuss why have them on the agenda" and it's because we're either done or stuck on something. If we're stuck we need to figure out how to get unstuck. Rossen: If there's nothing to do besides tests, let's get tests written. Perhaps we'll ask why there are no tests written or none reviewed. Rossen: So spending 15 minutes out of every call talking about people not doing what they were supposed to can suck, but it can be really productive. This is how we got SVG from something chaotic to something organizes and in CR. <dbaron> spending the first 15 minutes of every phone call asking people why they haven't done any work really sucks <dbaron> last time we did that I stopped attending the calls <fantasai> dbaron, +1 <tantek> dbaron, true, hopefully we can minimize it to 5 min ;) <tantek> hopefully we can reframe it as "Is there anything we can help with on this spec?" <ChrisL> it also sets up an expectation, so people tend to prioritize getting stuff done ahead of the call <ChrisL> tantek++ <fantasai> tantek, every call? the same answer almost every call <tantek> I am not a fan of shaming or berating people about "asking people why they haven't done any work" <tantek> in fact I am specifically against any such shaming or berating. totally unproductive and demotivating <tantek> fantasai, I think it's legitimate to ask "how can we help?" and also ok for editor(s) to say "no idea or you can't", until they think of something that does. <tantek> just asking the question, and respecting the editor(s) answers would be a good start Rossen: The same objections and comments were made with SVG. We ask these questions because we want to ship the spec. Those of you that ship on a regular cadence know how to do it. This mandated progress is a way to do it. Rossen: This is our current proposal from astearns and I. fantasai: First, on your list of specs, I think conditional rules, cascade and V&U should be on there. Rossen: Cascade was there. fantasai: Conditional rules, V&U, Backgrounds. fantasai: Text 3 isn't even in CR. I'm in favor of working on them, but there's things in addition to testing. fantasai: Second comment is until there are people doing testing as a significant part of their to do we won't make significant progress. Most of this work is not telecon work. It needs people that care about gathering tests. <gsnedders> (I was basically going to say what fantasai did) fantasai: Until we have people that have the time to do that we'll just talk status which is not useful. That's the problem we need to solve. We need QA people. It doesn't have to be actual QA people, but people who can QA. It can also be QA people. But if it's people doing this in their spare time we won't make progress. Rossen: In reply, once we see the testing work for a spec has taken off we can deallocate this spec out of conference call. Until then we need to support this work. ChrisL: I did publish for css 3 fonts there areas missing tests. A good 2/3 could be tested from myles' font, but it's mac OS only font. I can't make tests. That's what I'm stuck on. If I can get unstuck I can commit to tests. I'm asking for help. <gsnedders> ChrisL: I can potentially take a quick look, FWIW Rossen: Send me an e-mail and I'll connect you with out fonts guys. <tantek> ^^^ great example of the need help? ask for help. pattern myles: A couple thoughts. myles: I want to echo fantasai that the work remaining doesn't need to be on the call. myles: Second is I'm still fairly new as an editor so...I would love to take my specs to REC, but I need an mentor. I'm happy to work with ChrisL or anyone else. * ChrisL thinks Myles is doing a fantastic job editing fonts 4, actually myles: Point 3, ChrisL the font I'm confident I can make it work, I just need time. Which is kind of like point 1. The people doing this in their spare time, it's a matter of time and priorities. Rossen: I totally agree. Time is the only currency we have to spend and if we're constantly on credit we have problems. I want to force those conversations so people can ask for help. Given that we've made you the editor and you need mentoring, this is the time for you to ask. If we don't force those conversations we'll be stuck where there are all kinds of things to do and the progress gets slower. <fantasai> We should *absolutely* make sure that people feel welcome to bring up any issues that need WG discussion or help from other people. Just don't think that dedicating time every call to testing work is useful if none of that work is being done and there is therefore nothing to discuss. :) <tantek> fantasai, beyond "feel welcome", I think it's important to signal that the group prioritizes that <fantasai> tantek, sure <fantasai> tantek, don't mind to have a standing agenda item that's "Does anyone working on testing have anything to discuss" tantek: In response to fantasai, Rossen if we prioritize the CRs and then the mature WD as separate clusters I think that would help. Rossen: Definitely. The order we came up with was initial review of specs that seem close and stable enough in terms of not too much in terms of changes and mostly impl in browsers. We welcome feedback similar to fantasai's. We missed some. We can continue to refine the list on the private ML and continue to go forward. Rossen: If we don't start next call, perhaps, we should start the following. If we don't solidify the set of specs for next week, that is. <tantek> also we should encourage editors of CRs that need help to prioritize their requests / issues <tantek> over new WDs etc. Rossen: We're on the top of the hour. This is something that will take getting used to, but in the long run I'm hopeful and I think we'll get good results and send good signals to the rest of the community. fantasai: I just want to repeat that if you want to get to rec we need to get QA people in here, not just devs that also write specs. Rossen: Yes. That's noted. We'll see what can be done. As a group we have to be able to get our specs to REC. <tantek> fantasai, agreed, and we can also note that more broadly, e.g. to AC/AB that we are looking for more QA help. gsnedders: I just want to mention that the merge with web-platform-tests will happen in under a fortnight. <gsnedders> is the email I mentioned about that. Rossen: Thanks everyone. We'll chat next week.