- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 22 Jun 2015 14:17:09 -0700
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Bem Jones-Bey <bjonesbe@adobe.com>, www-style list <www-style@w3.org>
On Mon, Jun 22, 2015 at 1:52 PM, François REMY <francois.remy.dev@outlook.com> wrote: > Tab Atkins Jr. said: >> Agree that we should define serialization here. >> >> 1. calc() should serialize as a sum of unique uncombinable non-zero united >> values (where "uncombinable" is defined by whatever stage of computation >> the value is from: as a specified value you can only combine absolute units, >> numbers, etc; as a computed value you can combine em+px, etc.). >> Multiplication and division never show up in the serialized value; they exist >> solely to make some numbers easier to express. >> >> 2. I'm torn on whether a fully combined value should serialize as a >> calc() or as the value itself. There's no meaningful difference between the >> two; they do exactly the same thing (modulo bugs). In an object-based >> CSSOM, I'd have calcs stay as calcs no matter what you do to them, for API >> predictability. That isn't as necessary for serialization purposes, so I'm not >> sure which I prefer. Requiring it to stay as calc() means disallowing browser >> optimizations where they shift down to a plain value (rather than a calc() >> struct) when possible. > > (maybe we should also add to "1" an ordering for the units so that every browser serializes to "calc(Ax + By)" and not some to that and some to "calc(By + Ax)"; is any such order already defined in css?) There is no such ordering; I agree that there should be. For lack of anything better, and since the ordering has no behavioral significance, I suggest case-insensitive alphabetical order by unit, with % last. ~TJ
Received on Monday, 22 June 2015 21:17:56 UTC