- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 31 May 2018 23:49:45 +0000
- To: public-css-archive@w3.org
> the definition of division seems a little bit on the informal side -- "negate" / "negated" isn't formally defined, and I suppose it's not completely clear what it would mean for the percent hint on a type. (Can the type in a calc() ever have a percent hint?) Sigh, I knew that would be problematic, but hoped it was okay to be short with it. I added an "invert a type" algo to TypedOM and am using it directly now. > it's not clear what determines whether the result is <number> or <integer>, though I suspect that's a pre-existing issue. As Amelia said, that distinction is no longer necessary. > I'm worried that the clamping behavior (for infinities) is also underdefined. Interesting, what problems do you foresee? It should be identical to the existing clamping behavior for very-large-but-finite values; I can't imagine anything that would distinguish it from that case. ----- > Which is likely to go to CR first, Values 4 or CSS Typed OM 1? Maybe it would be better to move the full type checking definitions here, and then reference/overwrite them from Typed OM. I don't particularly care; if it becomes a publication issue I'll move things, but otherwise I'll just leave them where they are. > Regardless of whether or not you continue to link to Typed OM, it would be helpful if you actually define the type map concept in this spec before using it in the list of rules. I think that would be a distraction from the spec text. Even in Typed OM, the algorithms for types are off in their own subsection, separated from the actual operations that use them, because the details aren't particularly relevant for understanding things. The fact that following the definitions jumps to another document instead of a same-document separate section isn't a particularly relevant difference here. > The "In previous versions..." sentence should be pulled out as an informative note. Good catch, done. > Then, in the rule list, move the list of simple types up to be the first point in the list, as it provides an understandable example of what this means. I see the value of this, but I'm currently relying on it being last so I can say "anything else". For consistency I'd also have to move the final bullet point up, and I think it reads best put at the end. > Since that bullet point already handles converting percentages to their "hint" types, I think it just confuses matters to link to the Houdini "add the types" algorithm for the "+" operator. Sure, it's some indirection, but it's identical to the type-determining line of the `.add()` algorithm in TypedOM, and that sort of parallel construction helps highlight that there's nothing surprising. Rewriting it to be more explicit and reproducing the "add two types" algo makes this less obvious. I'm similarly against trying to inline the algorithms for multiplication and division. > Notably, with percent hints already resolved to other base types, there is no way for the type checking to fail in a multiplication operation. Ah, this is true. I'll simplify. > (The rules in Typed OM do not define mutually exclusive types, since they allow a «[ "percent" → 1 ]» type to match percent, length-percent, angle-percent, etc.) They *do* define mutually-exclusive types *among the types that I listed*. I didn't say that it can resolve to the `<*-percentage>` productions on purpose. > Per the decision in w3c/css-houdini-drafts#734 (comment), the "anything else" bullet point will need to be updated (although it might be best to keep that as a separate commit). I don't understand what needs to be updated - I wrote the spec text with the assumption that the issue would be resolved in the way I wanted, so it already defines how to handle `<flex>`. > The note about percentages and numbers not being combine-able needs to be updated, so that it doesn't reference division by other types being disallowed. Updated from future to present tense. ^_^ -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/545#issuecomment-393717221 using your GitHub account
Received on Thursday, 31 May 2018 23:49:47 UTC