W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [css-values] Comments on Serialization of calc

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 17 Feb 2016 15:48:09 -0800
Message-ID: <CAAWBYDACkyxkByQrHmSVk4KTGgZsjMzqcOfCdoGLP018wdz6ZA@mail.gmail.com>
To: Francois Remy <frremy@microsoft.com>
Cc: CSS WG <www-style@w3.org>
On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <frremy@microsoft.com> wrote:
> Hi Tab, Fantasai,
> Here are a few comments regarding the "calc" serialization section I just reviewed:
> https://drafts.csswg.org/css-values-3/#calc-serialize
> ----[0] Thanks for looking into this, you rock, as always!
> ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter?

It probably does need to be expanded on, but it's the same concept of
"absolutization" that transforms em into px at computed-value time.

> An alternative approach I would like to see investigated would be the following one:
> (a) define a canonical unit per type (length:px,time:s,...) or an ordered list of canonical units if needed
> (b) replace step 1 by something like "for each component of the sum, if it would possible to do so permanently, convert it into the canonical unit of the calc expression (specified values cannot be converted in a way that would make the conversion be invalid if the environment changes, computed values can)"
> This is a breaking change over your current approach which preserves 0vh for instance, while it would be converted to 0px in this case. We could add some additional condition that says that the validity of conversion is considered independently of the number put in front of the unit, which prevents 0 being an exception).

Agree with this in general.  And yeah, we'd combine based on units
only, not values.

> ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though.

Yeah, this step is based on browsers' current behavior. I'd prefer to
drop it if specifying fresh.

Received on Wednesday, 17 February 2016 23:49:02 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:57 UTC