W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2017

Re: [csswg-drafts] [css-values] Computed value of a negative calc unit that doesn't allow negative lengths.

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
Message-ID: <issue_comment.created-349821965-1512606908-sysbot+gh@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>
&lt;dael> Topic: [css-values] Computed value of a negative calc unit that doesn't allow negative lengths<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/434<br>
&lt;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>
&lt;bkardell_> present +<br>
&lt;dael> fantasai: Not quite. To clamp them both...twice effectively.<br>
&lt;dael> fantasai: Some values you can calc through at the beginning and others you can't.<br>
&lt;fantasai> Summary of the issue / proposal : https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908<br>
&lt;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>
&lt;dael> TabAtkins: That is what we're saying<br>
&lt;dael> fantasai: No it's not.<br>
&lt;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>
&lt;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>
&lt;dael> florian: So is there an argument against that?<br>
&lt;fantasai> s/at that moment/; other is you clamp when it's guaranteed to be possible for that property in general./<br>
&lt;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>
&lt;dael> TabAtkins: That might be possible<br>
&lt;dael> fantasai: I'ts not because font size prop needs to compute through to ems can be computed.<br>
&lt;dael> TabAtkins: Is that true though...<br>
&lt;dael> ??: I think so<br>
&lt;dael> TabAtkins: What's wrong with ems computing to a calc.<br>
&lt;dael> fantasai: ems are a length, they resolve to px<br>
&lt;dael> TabAtkins: THat's current. What's wrong with the other way around.<br>
&lt;dael> TabAtkins: It eentually falls through to layout. Only differencec is what things you can observe at computed value time.<br>
&lt;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>
&lt;dael> TabAtkins: Yeah, that would be the technical consiquencce. Every situation here is bad.<br>
&lt;dael> dbaron: That's bad for impl complexity and performance if you say you can never simplify.<br>
&lt;fantasai> s/..../but still have it resolve on the parent on the original element on which it was declared/<br>
&lt;dael> TabAtkins: Sure.<br>
&lt;dael> florian: What's wrong with clamp as soon as you can. It sounded good to me. It's fine with animations.<br>
&lt;dael> TabAtkins: Someone advocating for that would have to argue for it because I don't know.<br>
&lt;gregwhitworth> "as soon as you can..."<br>
&lt;dael> astearns: I'm still unclear.<br>
&lt;dael> TabAtkins: florian means what we're suggesting.<br>
&lt;dael> florian: As soon as you can based on alues, not based on which property it's in<br>
&lt;fantasai> A) Clamp as early as possible based on values.<br>
&lt;dael> dbaron: % will behave differently depending on how they behave for prop<br>
&lt;fantasai> B) Clamps as early as possible based on the property.<br>
&lt;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>
&lt;dael> dbaron: Are there cases...where we distinguish between calc 10% and 10% doing something different.<br>
&lt;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>
&lt;dael> fantasai: If it's negative. We throw those out at parse time<br>
&lt;dael> dbaron: If we want to throw out neg it also makes sense to simplify away the calc.<br>
&lt;dael> dbaron: If you're at a point where you can fix the negative you should comput calc to a single value<br>
&lt;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>
&lt;dael> florian: [missed]<br>
&lt;astearns> s/[missed]/editor concerns/<br>
&lt;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>
&lt;florian> a/[missed]/channelling glazou: when possible, keeping what the author wrote helps with authoring tools/<br>
&lt;dael> TabAtkins: For animation it's 0px<br>
&lt;dael> dbaron: But we're talking what the computed value is<br>
&lt;dael> TabAtkins: Well, what the animated value is. It's mostly the cocmputed, but sometimes diverges.<br>
&lt;dael> TabAtkins: Big obserable thing is in your animated behavior<br>
&lt;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>
&lt;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>
&lt;dael> TabAtkins: I don't have a strong opition but people have obj to removing calc before.<br>
&lt;dael> fantasai: Removing calc should be a sep/ issue<br>
&lt;dael> dbaron: It would also be useful to have links to the other decisions.<br>
&lt;dael> TabAtkins: I recall glazou being a proponent of maintaining calc<br>
&lt;dael> astearns: fantasai in IRC had 2 comments [reads]<br>
&lt;dael> astearns: My understanding is we're going with option A<br>
&lt;dael> astearns: Is that correct?<br>
&lt;dael> florian: Yes, I think so<br>
&lt;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>
&lt;dael> dbaron: I'm uncomfortable agreeing to clampa t a time when we're not agreeing to simplify calc at the same time<br>
&lt;dael> florian: Would you obj to not simplifying or is there another option<br>
&lt;dael> TabAtkins: I'm fine with simplifying. There were arguements against it before.<br>
&lt;dael> dbaron: I think we should table and go back to look at those arguments.<br>
&lt;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>
&lt;dael> florian: astearns when you make that it's good to mention glazou.<br>
&lt;dael> astearns: I will tag him on it.<br>
&lt;dael> TabAtkins: This is the only thing blocking CR and V&amp;U is quite out of date. Can we do a new CR with this unfinished and get it up to date?<br>
&lt;dael> astearns: How many other changes are in the changes section?<br>
&lt;fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2016<br>
&lt;dael> TabAtkins: I'll look. A decent amount. A number of new units<br>
&lt;dael> astearns: And we're in CR?<br>
&lt;dael> fantasai: The new units are in 4.<br>
&lt;dael> TabAtkins: Let me linkt he changes.<br>
&lt;dael> astearns: Given we're in CR I don't htink we can ask for updated before we republish.<br>
&lt;dael> TabAtkins: Then let's close it no change and re-open it because this is preventing us from publishing.<br>
&lt;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>
&lt;dael> astearns: Republishing and knowing we have to do it again is also dumb. I'd rahter wait.<br>
&lt;dael> florian: Does spec have the thing we're likely to resolve to?<br>
&lt;dael> TabAtkins: let me look<br>
&lt;dael> TabAtkins: Current spec says always clamped at used value which is the thing we agreed to not do<br>
&lt;dael> [laughs]<br>
&lt;dael> florian: So resolve unless glazou objects?<br>
&lt;fantasai> s/the thing/the one thing/<br>
&lt;dael> astearns: I don't want to rush this through.<br>
&lt;dael> astearns: I'm sorry.<br>
&lt;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>
&lt;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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:44 UTC