You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not clear whether this expression is invalid. Inside calc((), the types of arguments to the - operator must be compatible, and the rhs is of type dimension<length>. But what is the type of the lhs: number or dimension<length>?
Since section 5 says:
for zero lengths the unit identifier is optional (i.e. can be syntactically represented as the <number> '0'
I would argue that interpreting 0 as being of type dimension<length> would be valid, and would be more in line with developer expectations. However, this was discussed in 2010 with @tabatkins agreeing the 0 should cause a parse error. That's fine, but it would be helpful if the fact that 0 is never treated as a dimension inside calc() were explicitly noted in the spec (which was also agreed upon in that discussion).
The text was updated successfully, but these errors were encountered:
Section 8.1.2 **
calc()
Type Checking does not explicitly indicate how a unitless0
inside acalc()
expression is treated. For example:It's not clear whether this expression is invalid. Inside
calc(()
, the types of arguments to the-
operator must be compatible, and the rhs is of typedimension<length>
. But what is the type of the lhs:number
ordimension<length>
?Since section 5 says:
I would argue that interpreting
0
as being of typedimension<length>
would be valid, and would be more in line with developer expectations. However, this was discussed in 2010 with @tabatkins agreeing the0
should cause a parse error. That's fine, but it would be helpful if the fact that0
is never treated as a dimension insidecalc()
were explicitly noted in the spec (which was also agreed upon in that discussion).The text was updated successfully, but these errors were encountered: