neve
neve copied to clipboard
Codeinwp
Growable components for fixed size ones in header builder.
Description:
Based on the @Codeinwp/support team feedback let's see how we can improve a bit the auto-size or manual size of components.
- Let's audit first which components can have this mechanism.
- Can we use a range that can grow the size as much as we have space? Or a predefined list for width as Normal/Large/Extra Large for the width? The width calculation should be based on the space remaining in the row, not the full row space.
I've done some research, and there are some blockers for the implementation.
Because we're adding the components into slots, we don't have a clear way of setting a component width based on how much space is already used inside the row.
I've looked into alternatives, like allowing width control for individual slots (similar to how the core editor deals with columns). The problem with this approach is that each slot can contain multiple components positioned horizontally, so we can't set the inner component width to 100%, so it stretches inside the slot.
One way of doing this that I consider more useful in the long run would be to allow togging of the column layout + column number controls (that we use in the footer) on all the header rows.
We can accommodate inner content that the user might want to span across the whole row inside one column.
That might prove too much adjustment for this reason alone, as it would need a rework across the board, including allowing different setups for mobile vs. desktop (the footer automatically treats the mobile version through hardcoded CSS).
@cristian-ungureanu @preda-bogdan What do you think?
Hey @abaicus. It's been a while here with no response from me or @preda-bogdan and I want to apologize for that. I want to have a look over this in one of our daily meetings and see how we can proceed further.
Hey, I think this can only be achieved if we rewrite the header to support a dynamic grid system, this way you could place elements on specific sub-columns on a (12-16 col) grid, and there won't be a need for alignment classes and you can then control how much an element can grow.
However, this seems like a big refactor and you will also need to make sure you migrate the current layout to the new system. Another option would be to roll the new system as an opt-in but this will also lead to some more complexity as you would need to support both systems for a while.
IMO we should make sure that this is a much-needed feature for most of the users as the downsides of poor implementation or rollout might out way the benefits.
As a side note maybe we can target specific instances where this is required and find alternative ways to achieve the same thing.
Thank you!
After today's meeting, we agreed that we should first see if this is still relevant or if it was just based on people rejecting changes.
@Codeinwp/support can you help us a bit and let us know if this is still something that users are complaining of? The solution to this issue would be a pretty big refactor, and we're trying to understand if we should act on it.
@cristian-ungureanu Personally I haven't seen any tickets related to this in the last period of time. There were a few users who complained about it right after the change was made, but since then I haven't encountered other tickets where this issue was raised.
I remember a few tickets from past months: https://secure.helpscout.net/conversation/1901818276/324514/ https://secure.helpscout.net/conversation/1855469810/318521/