Hi,
I wanted to share this. It is not a bug per se but more of what I see from here as a design limitation that translates in unreliable editing.
But maybe I don't see the whole picture and it is as good as it gets and the fix i'm suggesting would break more things that it would actually fix.
It is about the use of "vw" over "%" in some cases.
First, they are shown as "%" in the back-end, which to me is confusing to see "vw" in the debugger.
Also I believe "vw" is sadly unreliable because it include the scrollbar in windows, but the viewport limits the content before the scrollbar. Which makes the unit unreliable depending on wheter your page has a scrollbar or not, if the user is using mac or pc. But that's all W3C's problem and that is not (not really) the issue here.
For layGridder, the use of vw translates in proportion issues :
If the gridder in our webpage is not full-width : those 56% of space-above in the exemple screenshot can become way out of proportion.
In the back-end, an element with 56% space above could be the same size as another element, and in the front-end, that first element could have doubled in height.
More over, in the sole back-end : if you resize your editing window, elements will start to change in proportions, and you will have no idear how it will actually look until you save, refresh, see for yourself on the front-end at a certain window width.
And while padding-top : 56vw; shows those limitations padding-top : 56% works perfectly in my tests within the gridder, always keeps the same proportions in front and back-end and no matter how you size your gridder in the page.
This is to me the way to go for layGridder because it needs to integrate into other peoples code as a plugin while layTheme can easely use vw because the whole sctructure evolves around the same system.
But Pierre, you could easely calculate how many vw is your padding-top: 56% :
My gridder is 70% of page width so : 70*0,56 = 39.2vw
So here we are : I just put space-above 39.2 and problem solved !
That's only assuming my gridder has a width based on "%", not px AND that that % is consistent. It us actually my case but some other layGridder users could alternate between 50, 60, 70, 80% depending on viewport size or even on user action.
But even for me, because of that W3C spec issues about how vw is calculated :
- if there is a scrollbar, padding-top:56% will actually be 38vw.
- If there is no scrollbar : padding-top:56% will be 39,2vw.
And that difference is specific to my screen resolution and would be again different for someone else.
So if there is no conflicts in the code, I don't see why we shouldn't use "%" instead of "vw" right away for element space-above, space-below ? And maybe a few other inputs could benefit from this also
If there is technical conflicts and it's not a 10 seconds fix as I thought :
I think it would be a very interesting addition to the lay family to offer more control around vertical space.
Just as we can "use browser height for row height". Maybe we could see a "set row height" option, with the ability to set a row height in "%" of the width (to have a fixed width/height row ratio) or set a custom "vh" height to have more control over how much we see at the same time.
Maybe could even have the option then to have "sub-rows" instead of "columns" (horizontal grid instead of vertical).
Testings (here, i'm forcing row height via custom css just to test out. The "green" element is my stack with padding-top: 56vw // 56%) :
vw :
% :
If someone wonders why I want a 56% padding-top on a empty stack element : it's because it results in a 16/9 aspect ratio to show to have every row the same size = the best size for video backgrounds.