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

Does the browser currently do early or late reduction of a sizing unit to actual pixels?  em is problematic, but does it bind early or late?  If I have --fs: 3em, is that evaluated to actual pixels in the parent or in the expression where it is used relative to the local font-size?  I expect the latter, which is perfect for this.

The expected use of this is from a certain high-level point in the DOM hierarchy down so that these kinds of variables would typically be defined within the same realm, all having the same unit * scaling values.

Your example does not illustrate what I am proposing.  20px would stay 20px all the way until it was actually used to size something.  So, neither early nor late binding, but very late binding.  There is no point where 20px becomes 40px in any CSS expression.  To mix pseudocode for logical internal functions and CSS a bit:

pxInPixels() { if (--px-map) return cachedEval(--px-map); else return window.pxPixels; }
emInPixels() { if (--em-map) return cachedEval(--em-map); else return window.pxPixels * emBase; }
.parent {
  --px-map-bad-example: calc(PX * 2);
  --lvw-scale: .0833; // 1200 px nominal 100% width.  This is the starting / fallback value, set in each webcomponent / environment.
  --vw-scale: .0833; // Set dynamically as needed, once at each top panel.
  --px-map: verylatecalc(PX*vw*var(--vw-scale, var(--lvw-scale)) // only eval at last step
  --foo: 20px;
  --alsoFoo: 20;
.child {
  px-mapping: initial; # default, not necessary.  Overriding prevents scaling for this component.
  width: var(--foo); // still 20px
  min-width: var(--alsoFoo)px;
Where cachedEval simply means memoizing until the dependent CSS variables change.

GitHub Notification of comment by sdwlig
Please view or discuss this issue at using your GitHub account

Received on Friday, 26 April 2019 19:48:14 UTC