From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>

Date: Thu, 05 Jul 2012 16:06:24 +0800

Message-ID: <4FF54B00.2090005@csail.mit.edu>

To: "Tab Atkins Jr." <jackalmage@gmail.com>

CC: WWW Style <www-style@w3.org>

Date: Thu, 05 Jul 2012 16:06:24 +0800

Message-ID: <4FF54B00.2090005@csail.mit.edu>

To: "Tab Atkins Jr." <jackalmage@gmail.com>

CC: WWW Style <www-style@w3.org>

(12/07/05 15:34), Tab Atkins Jr. wrote: > On Wed, Jul 4, 2012 at 12:09 AM, Kang-Hao (Kenny) Lu > <kennyluck@csail.mit.edu> wrote: >> (12/04/24 3:55), Tab Atkins Jr. wrote: >>> Issue 2: calc() and attr() need to resolve values that are normally >>> changed at computed-value time >>> Closed as Accepted - the spec now says "The computed value of a calc() >>> expression is the expression with all components computed, with all >>> multiplication/division subexpressions resolved, and with all >>> addition/subtraction subexpressions resolved where both sides are the >>> same type." >>> >>> Let us know if this is acceptable! >> >> Sorry but I just realized the current wording is sort of vague when >> talking about a corner case: 'height: calc(0*0%)'. It is treated as >> 'height: auto' in IE9, Firefox13 and a Chrome version with >> '-webkit-calc', similar to 'height: 0%', not 'height: 0'. >> >> Therefore, the note >> >> # Thus, the computed value of a ‘calc()’ expression can be >> # represented as either a number or a tuple of a dimension and a >> # percentage. >> >> is sort of inexact in that it doesn't say '0' and 'undefined' are different. >> >> >> The spec should provide a hint to css3-flexbox too. calc(0*0%) should >> probably be treated as indefinite if resolved against an indefinite length. >> >> >> Also, I think "same type" in the quoted prose here should be elaborated >> a little bit. The rest of the description of 'calc()' talks about >> "resolved type", but both <percentage> and <length> have the same >> "resolved type" for the cases we care. >> >> Proposed wording (just a try): >> >> | The computed value of a calc() expression is the expression with >> | all components computed with all multiplication/division >> | subexpressions resolved, and with all addition/subtraction >> | subexpressions resolved where both sides are the the same type, >> | unless one of which is <percentage> (which doesn't compute to an >> | absolute unit) and the other isn't. User agents must track whether >> | a <percentage> is contained a calc() with a flag. >> | >> | If 'height' is specified with calc() containing a <percentage> >> | , the value must be treated as 'auto'. A length specified with >> | calc() containing a <percentage> when the <percentage> is resolved >> | against an indefinite length is an indefinite length. Otherwise, >> | it's definite. > > I don't think we need to make this change. The type resolution rules > definitely state that if you multiply a number with something else, > the type is the "something else". So, "0 * 0%" will resolve to a > percentage (or rather, the resolved type of the percentage). No, the resolved type of <percentage> is <length> and you can't resolve to it at computation time (unless the property is 'font-size', 'line-height' or 'vertical-align'). > This means that it'll be representable as a length/percentage tuple, > and receive normal handling for that case. Let me restate my main issue again: Issue: There's is no normative stating when and what 'calc()' is treated as 'auto' when used in 'height'. Either this spec or css3-box should specify this. Is your intention to defer this to css3-box? css3-values has # Given the complexities of width and height calculations on table # cells and table elements, math expressions involving percentages # for widths and heights on table columns, table column groups, table # rows, table row groups, and table cells in both auto and fixed # layout tables MAY be treated as if ‘auto’ had been specified. too so it seems the right fit here. Cheers, KennyReceived on Thursday, 5 July 2012 08:07:22 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 16:28:45 UTC
*