- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Dec 2017 00:35:09 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `[css-values] Computed value of a negative calc unit that doesn't allow negative lengths`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-values] Computed value of a negative calc unit that doesn't allow negative lengths<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/434<br> <dael> astearns: I added some tests with idea we would want to be picking either use or computed time. Sound proposal is to clamp as soon as possible. Correct?<br> <bkardell_> present +<br> <dael> fantasai: Not quite. To clamp them both...twice effectively.<br> <dael> fantasai: Some values you can calc through at the beginning and others you can't.<br> <fantasai> Summary of the issue / proposal : https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908<br> <dael> dbaron: I think what I suggested is that when the value...when all values of prop can be computed through at computed value you clamp t computed value time. If not you clamp at used value time<br> <dael> TabAtkins: That is what we're saying<br> <dael> fantasai: No it's not.<br> <dael> fantasai: There's two proposals. One is you clamp at each stage if it's possible at thtat stage for values under consideration at that moment.<br> <dael> TabAtkins: The answer is the forward compat one. A prop is used value clamping if any property needs used value time to tell. It will have an observable effect if we later add an item that is used to a clamp. The clamp as early as you can has no observable effect when we add new things to value space.<br> <dael> florian: So is there an argument against that?<br> <fantasai> s/at that moment/; other is you clamp when it's guaranteed to be possible for that property in general./<br> <dael> astearns: My question is since clamping at used value appears to be slightly useful for animmations could we only clamp at used value time?<br> <dael> TabAtkins: That might be possible<br> <dael> fantasai: I'ts not because font size prop needs to compute through to ems can be computed.<br> <dael> TabAtkins: Is that true though...<br> <dael> ??: I think so<br> <dael> TabAtkins: What's wrong with ems computing to a calc.<br> <dael> fantasai: ems are a length, they resolve to px<br> <dael> TabAtkins: THat's current. What's wrong with the other way around.<br> <dael> TabAtkins: It eentually falls through to layout. Only differencec is what things you can observe at computed value time.<br> <dael> fantasai: It means you'll carry a calc around that's 50px+100%+2em you have to carry that and insert it into a margin that's a descendant of a descenent .... are you crazy?<br> <dael> TabAtkins: Yeah, that would be the technical consiquencce. Every situation here is bad.<br> <dael> dbaron: That's bad for impl complexity and performance if you say you can never simplify.<br> <fantasai> s/..../but still have it resolve on the parent on the original element on which it was declared/<br> <dael> TabAtkins: Sure.<br> <dael> florian: What's wrong with clamp as soon as you can. It sounded good to me. It's fine with animations.<br> <dael> TabAtkins: Someone advocating for that would have to argue for it because I don't know.<br> <gregwhitworth> "as soon as you can..."<br> <dael> astearns: I'm still unclear.<br> <dael> TabAtkins: florian means what we're suggesting.<br> <dael> florian: As soon as you can based on alues, not based on which property it's in<br> <fantasai> A) Clamp as early as possible based on values.<br> <dael> dbaron: % will behave differently depending on how they behave for prop<br> <fantasai> B) Clamps as early as possible based on the property.<br> <dael> TabAtkins: We're saying as early in the context of a property. Since in the property you can tell if you can know at computed and clamp them or you wait until used.<br> <dael> dbaron: Are there cases...where we distinguish between calc 10% and 10% doing something different.<br> <dael> TabAtkins: I don't think so. In position % don't resolve to a simple pixel value, but still a bare % goes to same in or out of call<br> <dael> fantasai: If it's negative. We throw those out at parse time<br> <dael> dbaron: If we want to throw out neg it also makes sense to simplify away the calc.<br> <dael> dbaron: If you're at a point where you can fix the negative you should comput calc to a single value<br> <dael> TabAtkins: That's against our general consesus to maintain calc structures somewhat so that authors get to look at a regular thing. I've argued against that, but that was what the group wanted.<br> <dael> florian: [missed]<br> <astearns> s/[missed]/editor concerns/<br> <dael> dbaron: I don'ts ee how you maintain a calc structure while clamping. If you have 50px+2em and you know an em is large, do you change the em or do you turn it into 0px?<br> <florian> a/[missed]/channelling glazou: when possible, keeping what the author wrote helps with authoring tools/<br> <dael> TabAtkins: For animation it's 0px<br> <dael> dbaron: But we're talking what the computed value is<br> <dael> TabAtkins: Well, what the animated value is. It's mostly the cocmputed, but sometimes diverges.<br> <dael> TabAtkins: Big obserable thing is in your animated behavior<br> <dael> dbaron: I guess...you could compute it to calc 0px rather then 0px. But it seems weird to deal with clamping but not simply expressions.<br> <dael> astearns: Seemes weird to me to have a clamp happen but then give the non-clamped expression and the person using it doens't know if it's eval as expression or clamped value.<br> <dael> TabAtkins: I don't have a strong opition but people have obj to removing calc before.<br> <dael> fantasai: Removing calc should be a sep/ issue<br> <dael> dbaron: It would also be useful to have links to the other decisions.<br> <dael> TabAtkins: I recall glazou being a proponent of maintaining calc<br> <dael> astearns: fantasai in IRC had 2 comments [reads]<br> <dael> astearns: My understanding is we're going with option A<br> <dael> astearns: Is that correct?<br> <dael> florian: Yes, I think so<br> <dael> astearns: What if we resolve on option A: Clamp as early as possible based on values. and I'll open a new issue as to what to do with calc when they're clamped<br> <dael> dbaron: I'm uncomfortable agreeing to clampa t a time when we're not agreeing to simplify calc at the same time<br> <dael> florian: Would you obj to not simplifying or is there another option<br> <dael> TabAtkins: I'm fine with simplifying. There were arguements against it before.<br> <dael> dbaron: I think we should table and go back to look at those arguments.<br> <dael> astearns: I'll add a comment that we need to look at why we had been decising to preserve calcs. This being a new situation where we're clamping the value I suspect the previous arguments about preserving calc-ness will go out the window.<br> <dael> florian: astearns when you make that it's good to mention glazou.<br> <dael> astearns: I will tag him on it.<br> <dael> TabAtkins: This is the only thing blocking CR and V&U is quite out of date. Can we do a new CR with this unfinished and get it up to date?<br> <dael> astearns: How many other changes are in the changes section?<br> <fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2016<br> <dael> TabAtkins: I'll look. A decent amount. A number of new units<br> <dael> astearns: And we're in CR?<br> <dael> fantasai: The new units are in 4.<br> <dael> TabAtkins: Let me linkt he changes.<br> <dael> astearns: Given we're in CR I don't htink we can ask for updated before we republish.<br> <dael> TabAtkins: Then let's close it no change and re-open it because this is preventing us from publishing.<br> <dael> fantasai: I think we can ask for republish and explain this is a minor issue and still open and we'll deal with it.<br> <dael> astearns: Republishing and knowing we have to do it again is also dumb. I'd rahter wait.<br> <dael> florian: Does spec have the thing we're likely to resolve to?<br> <dael> TabAtkins: let me look<br> <dael> TabAtkins: Current spec says always clamped at used value which is the thing we agreed to not do<br> <dael> [laughs]<br> <dael> florian: So resolve unless glazou objects?<br> <fantasai> s/the thing/the one thing/<br> <dael> astearns: I don't want to rush this through.<br> <dael> astearns: I'm sorry.<br> <dael> TabAtkins: I'm jsut frustrated that we cna't publish because proccess. I'd rather publish and publish again in a montht hen have a month of buggy TR draft.<br> <dael> astearns: I agree on regular WD but CRs are extra work.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/434#issuecomment-349821965 using your GitHub account
Received on Thursday, 7 December 2017 00:35:13 UTC