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

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

From: Stephen Williams via GitHub <sysbot+gh@w3.org>
Date: Thu, 25 Apr 2019 09:23:37 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-437095184-1556184216-sysbot+gh@w3.org>
sdwlig has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-shadow-parts] PanResp (Panel Responsive) support: sizing expression mapping ==
This could be added to this specification, or a new specification might be more appropriate.  However, I'll suggest it here as it is part of the problem this spec is solving and it would be better to have this sooner.  The change is small, easy to implement, shouldn't have any effect when not used, and no security or other negative implications when used.

I created and have been using a new technique for a better kind of responsiveness that I call PanResp - Panel Responsive (where panel means any element, div, etc.).  Without going into too much detail here, the point of this method is to have fine grained control over sizing of information on a per-panel basis, allowing for breakpoints after which all content is scaled down smoothly, in partly non-linear fashion.  This technique also allows independent per-panel zoom.  I'm in the process of publishing details, examples, and an npm package.  While it would be great if the technique was native to browsers, it isn't too difficult to add to an application, except for being able to completely update the style of elements.  Each size-specifying CSS variable needs to use a small formula that uses CSS variables.

With custom elements, this means that every size-specifying CSS declaration has to be updated.  Normally, the results of this update look the same as before the update until a responsive scaling is activated.  Because of shadowRoot, if everything is not exposed, a parallel modified version of every library is needed.

Modified versions of libraries could be avoided, and not affect stylability choices otherwise or require parallel versions of libraries, if there were a way to transform all size-specifying CSS expressions with the same scoping as a CSS variable.  I.e., flowing downward through the DOM with different element trees using different expressions and/or variables.

What I propose here is to have a way to indicate a rule, perhaps as a CSS variable or something that works like a CSS variable, for each CSS sizing type: px, em, rem, pt, etc.  The rule would take the value or expression result and place it in an expression that could map to another type with a factor.  For example:
* --css-size-type-mapping-px:  calc(PXvw*var(--font-scale, var(--lfont-scale)))
* --css-size-type-mapping-em:  calc((16*EM)vw*var(--font-scale, var(--lfont-scale)))

where PX is the original expression, like 16px, and the EM expression might be 1.5em.  Internally, this mapping can happen once each time a CSS expression is changed, then handled normally on each evaluation.

Actually being able to run Javascript to perform computation and mapping would be even better, similar to the rendering and other callbacks that are coming, but this simple expression mapping solves the shadowRoot problem well enough.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3874 using your GitHub account
Received on Thursday, 25 April 2019 09:23:39 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:46 UTC