W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2019

Re: [csswg-drafts] [css-shadow-parts] PanResp (Panel Responsive) support: sizing expression mapping (#3874)

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Fri, 26 Apr 2019 18:24:33 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-487155079-1556303072-sysbot+gh@w3.org>
What I think you're proposing here is a way to change the "size" of certain units, right?

An easy way to do this today is to use a variable as a "base size" rather than using units directly; that is, write `width: calc(var(--px) * 5)` instead of `width: 5px`. It's definitely verbose, but it works everywhere. ^_^

At some point in the nearish future we'll have custom functions, so you could instead write this as `width: --px(5);`; this'll be backed by a JS function, so you can map it to a length however you want. (This isn't specced yet, but they're the next thing on my list for CSS Houdini specs.)

All in all, I think leaning on this sort of functionality makes more sense here. Adding a new implicit-conversion functionality that makes a length like "16px" not be 16px would end up being more confusing, I think. For example, what happens if someone writes `--foo: 20px;` on an element with this sort of mapping? If it's unregistered, the length won't be interpreted as such; it'll inherit down as the value "20px" and be interpreted with whatever the mapping is on the descendant that uses `var(--foo)`; if it's registered, it'll be converted early and inherit as the altered size. We already have this sort of "early or late" problem with some functions in variables; extending it to *all lengths* would be pretty confusing, I think.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3874#issuecomment-487155079 using your GitHub account
Received on Friday, 26 April 2019 18:24:40 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:07 UTC