- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 May 2018 20:35:23 -0400
- To: www-style@w3.org
========================================= 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 Grid -------- - RESOLVED: Accept proposed edits in https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268 to amend grid algorithm. - RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2697 (add align-content content distribution for this specific case (all rows have definite max size) to the row estimation heuristics for step 1). - RESOLVED: Close this issue, won't fix. (Issue #2270) - The group felt it was too early to create a shorthand and that more time was needed to figure out which of the many ways to set equally sized columns/rows should be represented in a shorthand. - RESOLVED: Accept this change but keep the issue open and don't do edits until there's an implementation commitment. (Issue #2681) CSS Images ---------- - RESOLVED: Always expand gradient syntax in serialization. (Issue #2714) Values & Units -------------- - The changes to allow unit algebra in calc() have been put in the spec and anyone interested was asked to review. Spec: https://drafts.csswg.org/css-values-4/#calc-type-checking Issue: https://github.com/w3c/csswg-drafts/issues/545 Selectors 4 ----------- - RESOLVED: Make specificity of :not() :has() and :matches() not depend on matching. (Issue #1027) ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0047.html Present: Rachel Andrew Tab Atkins David Baron Amelia Bellamy-Royds Garrett Berg Tantek Çelik Emilio Cobos Álvarez Alex Critchfield Benjamin De Cock Elika Etemad Simon Fraser Tony Graham Dael Jackson Chris Lilley Myles Maxfield Thierry Michel Liam Quin Melanie Richards Dirk Schulze Jen Simmons Alan Stearns Lea Verou Eric Willigers Regrets: Rossen Atanassov Dave Cramer Michael Miller Manuel Rego Florian Rivoal Jeff Xu Scribe: dael Agenda Setting ============== astearns: Let's get started astearns: Is there any changes to the agenda to make? <TabAtkins> The one change I sent to the thread? <leaverou> https://github.com/w3c/csswg-drafts/issues/2714 leaverou: I was wondering if we could add ^ to the agenda? leaverou: It's gradient serialization so hopefully fast. astearns: Let's try and do that after grid. astearns: TabAtkins you mentioned a change I think I made. astearns: TabAtkins was that adding editors? TabAtkins: The change I requested isn't in the agenda. astearns: Change you wanted? TabAtkins: Adding editors. astearns: It's first Adding editors to specs ======================= astearns: Fergal Daly is going to be editor for shadowparts. Chris Harrelson will be compositing and geometry astearns: They both joined. TabAtkins: Approved for adding Fergal Daly for shadowparts. The work Chris will do is much needed. astearns: So that's mainly informative. astearns: Their first task will be adding themselves as editor. TabAtkins I expect you'll help. TabAtkins: Yes. CSS Grid ======== Applying 'justify-content' content distribution is in the wrong place in the overall grid sizing algo --------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2557 <fantasai> https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268 fantasai: Summary is here ^ fantasai: When we size the grid we do all the sizing account for items etc. and at end align the track or justify them. Problem is that sometimes this increases size of gap so spanning item has more space. fantasai: Mats said we should integrate alignment into sizing algo more close so that you have alignment effects on sizing accounted for when doing sizing. fantasai: Seems like everyone agrees this is a good idea so bringing to WG for approval. fantasai: Questions? astearns: Comment you linked to has...does it have both 1.5 and 2.5 that are in further discussion? fantasai: 1.5 is second sentence in 1. astearns: And 2.5 is second sentence in 2? fantasai: Yes and so on down. astearns: Other comments to add? astearns: Objections to accepting https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268 RESOLVED: Accept proposed edits in https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268 to amend grid algorithm Applying 'align-content' content distribution to row estimation in step 1 in Grid Sizing algo ------------------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/2697 fantasai: Follow-up we have a heuristic to get rough sizes and we need to also change the heuristic fantasai: Technically different issue. fantasai: I think this is a matter of getting it correct. astearns: Additional comments? astearns: Objections to accepting https://github.com/w3c/csswg-drafts/issues/2697 or do people need time? RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2697 Shortcut syntax for repeat(M, 1fr) ---------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2270 leaverou: I found that I was using grid template columns and rows numbered by accident and realized that's not how you make equal columns and I was wondering if we can add shortcut syntax so the error becomes correct because I suspect other people would write this. leaverou: TabAtkins raised point that because we allow unitless lengths grid-template:0 has a meaning. It doesn't mean it's not possible, but it's confusing in that case. leaverou: People have discussed a new unit, I don't remember names, but people discussed units or functions like efr. I'm not a huge fan because I wanted to prevent this error and other syntax would get people to make errors. But I guess a shortcut for this is still a net gain. fantasai: My main concerns where that there's lots of sizing functions you can have and I'm not sure fr is what you always want. leaverou: My point was a shortcut to spec equal width columns. It can be a shortcut to whatever you think it should be. You know grid better then me. TabAtkins: The point isn't one better, but it's that there isn't a single obvious choice. It's hard to justify one with a blessing of a shorthand. jensimmons: I'd hesitate to put a thumb on the scale for which syntax should be used by giving one approach a special short hand. I feel industry needs a couple years to come up with a bazillion ways to do things. astearns: I wonder if we should let it sit, see if preprocessors come up with a shorthand of their own we can adopt. rachelandrew: Agree. I don't see huge confusion. I see people that love shorthands, but I don't see this as a mistake. I see a lot of not working grid and this hasn't come up. jensimmons: I see people trying to systematize and it's early for that. They don't understand power of grid and what a fr is. I think there's a long way to go before we create a system of shortcut. astearns: Is there anything we can do about the mistake case? fantasai: I think we leave as invalid. We could revisit a shorthand in the future but I think for now it's not the right time. fantasai: Related: one frustration raised in thread is way fr units are calc and people are frustrated you can't use direct because auto min is often wrong. We need to fix those cases. They have to set a 0 min. That's #1865. We need to do something about it. <fantasai> https://github.com/w3c/csswg-drafts/issues/1865 astearns: leaverou are you okay closing this for now and taking some of this over to 1865? leaverou: Yep, fine. I was fine since TabAtkins pointed out grammar inconsistency. astearns: We'll leave it there and not do anything for the moment. We'll see what people do with fr and make shorthands. RESOLVED: Close this issue, won't fix. gCS() of grid-row-start/etc properties should return used values? ----------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2681 TabAtkins: Someone brought up question of, it would be useful to know what row and column a grid element ended up in for scripting. TabAtkins: The requests are all solvable if we solve this. In particular if you do auto placement. Clearest way to do this is make sure used values are actual lines the properties end up with. Changing gCS() to return used value. TabAtkins: This is a change for all impl, they all return computed. It is more consistent with all other grid properties. Solves a useful use case without us having to add an API. With luck compat is low and huge benefit, but I want to get WG opinion. astearns: Used value is a line number index? TabAtkins: Yes <fantasai> +1 to the change, per TabAtkins’ rationale emilio: Do implementations preserve that info after layout? not sure they do TabAtkins: Don't know, but they have it at some point. dbaron: Not a fan of interesting things in gCS(). I see used value as legacy not to repeat. Slight pref for separate API but not strong <gsnedders> I am +1 of dbaron's point here TabAtkins: Separate API one thing is a bit awkward to compute. He wanted to know how large implicit grid is. I'm okay with either way. Thought pile into gCS is easier, but okay with both. astearns: There are other things in grid returning used? TabAtkins: grid-template properties give used values TabAtkins: That's because it's how Microsoft and Chrome did it initially fantasai: Microsoft asked to keep because it was compat for them. We put in spec so Chrome & Firefox did it. fantasai: I think a special API for grid to get interesting things is good. It will take a while to figure out what it should look like and where it goes and do we want layout mode APIs for other modes. It's a big project. Modifying gCS() gets us most of what we want. Information you're otherwise losing doesn't seem like it's that valuable. You can't get used values at all. fantasai: Since we're already returning used for other things if we switch we let people build the APIs they need to explore the grid. fantasai: In general I prefer less exceptions but in this case I think the usefulness and the time it would take to go the other route I think it points that we should change gCS() astearns: Summary: because it would take too long to do it right we should do it wrong TabAtkins: Not exactly wrong. fantasai: If gCS() wasn't already a mix of used and computed I would say don't do that. It is a mix and it's largely legacy driven we may was well go with utility. frremy: I think I agree with proposal. It's useful and not complex to do. Makes sense. astearns: Houdini APIs when you ask computed you'll get computed? TabAtkins: Yes. fantasai: And that's true in all cases where we return. dbaron: If you're making a change incompatible with all impl you need to have someone commit to try it soon rather then sticking it in and hoping someone will implement in a few years. We don't want dependencies on that decision. TabAtkins: Valid, yes. <tantek> right, who is willing to provide an intent to implement this? frremy: I'm not technically worried. Right now you get auto. If you're trying to do something with that you'll get a right value. I don't think it's a compat problem. I agree we should impl sooner rather then later. astearns: Are you volunteering? frremy: Don't know about that. But don't think it's complex. We should do it. astears: Any volunteers? TabAtkins: I'll ask Igalia folks and bring it back. astearns: dbaron has a point that longer it sits in spec moldering the worse it'll be. astearns: We can wait on resolving until a commitment. We can resolve and revisit in a month and if not move to impl revert? TabAtkins: Resolve to do the change, not change spec until commits, and add edits in a month if someone adds <AmeliaBR> There probably needs to be at least a resolution that implementers can point to in their bug trackers. astearns: prop: Accept this change but keep the issue open and don't do edits until there's an impl commitment astearns: Objections? RESOLVED: Accept this change but keep the issue open and don't do edits until there's an implementation commitment. astearns: AmeliaBR has a point it would be great if people could put an issue in your own bug tracker emilio: I looked at other grid properties. it's kind of slow but it works. I'll file and CC him. If no strong opinion I can impl. TabAtkins: Since gCS requires compute up front that is an argument for separate API. Then we can lazy compute dbaron: It doesn't require computing everything up front because it's a live object emilio: Right. You only compute when do getPropertyValue call TabAtkins: Right, nevermind. astearns: Should we reverse resolution? TabAtkins: No. <fantasai> We should add an issue note in the draft tho CSS Images ========== Clarify how gradients should be serialized in presence of the double-position color syntax ------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2714 leaverou: A few weeks ago we cleared the 2 position color stop for shipping. Right now chrome serializes any gradient with 2 colors stops with same color Chrome uses this syntax. Worried will break code. leaverou: Options either gradient read back as it's specified or canonicalize gradients. If 2 color stops have same color they're compressed. Or never canonicalize and always use the expanded syntax leaverou: No strong opinion. Worried about canonicalizing existing not spec this way. It could break parsing code. I would vote for another. Probably return expanded syntax in all cases. No strong opinion. <AmeliaBR> I'd also lean towards serializing with the older/explicit syntax, instead of the newer one. The new syntax is just sugar for declarations. dbaron: I think 2 principles on how to define serialization. 1 is that you want to try and serialize to shorter form. That's weaker in this case. Other is a syntax that's evolved over time you want to serialize to older. dbaron: I think the older form principle should win over shorter. That still leaves remember how it was spec or always expand syntax. No strong opinion between those. TabAtkins: How long ago did we ship always collapse? emilio: Hasn't yet. leaverou: Intent to ship was a few days ago. It's Chrome 69. emilio: It needs the three LGTM's to ship. Needs to be resolved on this. <leaverou> Correction: That's conic-gradients that will ship in 69. The 2 position syntax may ship later. TabAtkins: I was hoping we had shipped with no compat. Then I vote always expanded because keeping track of syntax is an extra bit on every stop that's not otherwise needed. frremy: Always expand seems better. leaverou: Agree. emilio: Seems good to me. Forget everything at parse time. TabAtkins: I assume that currently we're forgetting at parse time then eagerly collapsing and then going back and we can delete that bit and make it simplier astearns: Objections to always expand gradient syntax? RESOLVED: Always expand gradient syntax in serialization. CSS Align ========= Rules for align/justify-self on static position of absolutely-positioned boxes need more detail -------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1432 fantasai: We discussed this last week or the week before. TabAtkins: 2 weeks. fantasai: Issue was defining impact of various align. I think discussion had some confusion about I don't want sizing to depend on alignment. fantasai: To clarify we have the sizing of an abspos item depends on direction property of static pos containing block. fantasai: Suggesting to look at justify-content property instead on that containing block so author can control behavior without effecting bidi. No change in element looked at, just what element. fantasai: One case not covered is there's a center value in justify-content and we had to define a value for center. fantasai: To revisit the behavior if you have a static pos you use as the containing block size you use the start edge of the static pos containing block and end of abspos containing block. fantasai: That depends on direction fantasai: TabAtkins and I decided that since we can get the behavior for both then for centering both should key off the static containing block for both sides. fantasai: That's a summary. astearns: I see Rossen was involved 2 weeks ago, but he's not on this week. frremy: I don't have the right context to talk. We should probably wait for Rossen to be back astearns: fantasai and TabAtkins was Rossen adding useful things or moderating? fantasai: dbaron and Rossen had definite opinions. He was participating. astearns: You okay waiting until he's back? fantasai: Sure. astearns: We'll postpone again. Values & Unites =============== Allow division of same types in calc() -------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/545 astearns: Looks like there's a change for this. TabAtkins: I think all that's left is...I wanted review by WG. TabAtkins: I added the resolution from months ago to allow unit algebra in calc(). dbaron gave me review which I hadn't seen yet. I'll resolve those. Any other comments or concerns please let me know. It's in the spec frremy: I'm wondering how you decided the final unit value of a calc. You probably have to back track. I think we have to change how we do this. Seems fine by me, but it requires keeping track of more things TabAtkins: Yep, how to determine type it resolves to is in the spec and you need the algorithm to do Typed OM. I leaned on Typed OM as much as possible because I think I got it right. chris: This is the correct thing to do. It's compatible with typed OM we should do this. astearns: This edits is a result of a resolution? TabAtkins: Yes. We've had multiple resolutions to do this. dbaron found one in 2014. This is just a review request. astearns: Sounds like dbaron looked. chris and frremy are okay. I think we're good. Anyone else wanting to look please do. <TabAtkins> frremy: https://drafts.csswg.org/css-values/#calc-type-checking for details on how to resolve the type (final resolution step is below the <dl>, but relies on the machinery defined above it) Selectors 4 =========== reconsider specificity rule for :matches() ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/1027 dbaron: I originally filed this, but don't have a strong opinion on decision. Spec needs to be clear on which. <fantasai> List of options for considerations - https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-354655842 TabAtkins: Other people have argued one direction: :matches() can introduce some thorny issues on selector inheritence. :matches() specificity is as specific as the most specific branch. More than one :matches() with combinators in the branches...you get...you get a combinatorial explosion. You get 100s or 1000s of selectors without going deep TabAtkins: Naive calc() is expensive for memory and unbounded costs. TabAtkins: Suggestion was don't bother with that. Resolve it the same as :not() and :has() where its specificity of the most specific branch. So if you put an ID or a tag it'll be that. That's straight forward and matches other similar pseudo classes. <dbaron> wait, :not() and :has() do that? TabAtkins: Only problem is that pre-processors doing :matches() ahead can only do it with expanding. @extend in SASS will result in a specificity change. It's not a backwards commpat issue but may be a problem with people or SASS trying to switch to doing the new stuff. astearns: [reads dbaron comment] TabAtkins: I believe it's correct. fantasai: :not() takes specificity of most specific argument that didn't match. TabAtkins: :not() takes a full selector list TabAtkins: There's a note. "is replaced by specificity of most specific element" Also says it has the exact behavior of :not(:matches(argument)), which is a lie. That's not true according to spec. ericwilligers: Pointed out a few lies in my comment on the issue. TabAtkins: If you look at section 16 :matches() and :has() uses the branch that matches and :not() uses the most specific regardless of matching. frremy: I have another proposal, we don't allow combinators inside :matches() fantasai: We had that for a while. Original :matches() had everything. Implementors said too complex, we took it out, impl then said they want it. So I think we have implementations that handle complex selectors fantasai: [some confusion about combinators vs commas] frremy: Commas is the whole point of :match() I said combinators TabAtkins: Combinators are the difficulty frremy: :matches() without combinators is easy. TabAtkins: Without combinators, just making it compound, doesn't simplify. Still have branches. Look at HTML on list bullets. It's a big list. If you do a simple :matches() rule you still have combinatorial branching. emilio: Removing combinators makes it simpler. <TabAtkins> `:matches(a, #foo) :matches(a, #foo) :matches(a, #foo)` <= naively expands to 8 choices anyway <TabAtkins> `:matches(a, #foo, .bar) :matches(a, #foo, .bar) :matches (a, #foo, .bar)` <= naively expands to *27* choices anyway <TabAtkins> `:matches(.a .b .c, .d .e .f)` expands even faster, of course - expands to over a dozen combination, don't wanna compute the actual number right now because it's non-trivial dbaron: Thing that's still hard is if you leave commas and you can have multiple matches and have you have backtrack to find the right one. As you walk up ancestors you might match the first on the element and a match for the second with ID but have to try ID ID path frremy: Oh, I see. emilio: Making specificity a property of the selector is nice, I think. TabAtkins: I see the difficulty and I'm happy to simplify it frremy: I think proposal is in the right direction. Easier to impl if only compute specificity of the selector as a selector. I can see why people would be confused, but I think it's simpler. ericwilligers: Same for :not() and make it most specific if it matches or not? frremy: Yes dbaron: I'd be more concerned with this proposal if I thought specificity was more useful, but I think most people fight with it. astearns: I'm hearing at least 3 things. astearns: 1) places where current spec lies. Need resolutions on those? TabAtkins: Won't be a lie once we resolve. astearns: 2) Removing combinators in :matches() TabAtkins: I'd like to keep that separate and reject it. astearns: 3) What we're doing for :matches() and :not(). Is there consensus? dbaron: Consensus to make specificity is only a function of the selector and not the element. astearns: Specificity on :not() and :matches() depends on selector and not any possible matching. TabAtkins: Should do for :has() as well. astearns: Do not consider matching when determining specificity of :not() :matches() and :has() <TabAtkins> proposed resolution: :matches() and :has() should only consider their selector arguments (using most specific argument) rather than which branch matched, like :not() currently does. ericwilligers: Doesn't know why :has() needs specificity TabAtkins: You can't right now, but in theory an impl could allow it. astearns: Having a non-testable assertion is annoyi.ng fantasai: Of course has needs specificity. TabAtkins: You can only use it in JS so specificity doesn't do anything. fantasai: but if we ever use it in stylesheet TabAtkins: Current spec has an assertion, we should make it consistent. astearns: Objections to making specificity of :not() :has() and :matches() not depend on matching RESOLVED: Make specificity of :not() :has() and :matches() not depend on matching. astearns: Thanks everyone for calling in and we'll talk next week
Received on Thursday, 31 May 2018 00:36:21 UTC