-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Restrict box styles to certain container slots #431
Comments
@arnalyse I assume that you do not mean box styles nor boxes, but teaser formats, right? Besides my former position, I heavily support this proposal. With the Presidential Suite having now around a dozen teaser-formats theming all of them for all slots is madness. And most editorial staff don't want this flexibility. The central problem to be solved is: What happens, when a place a given box into a slot, choose a teaser format that is valid within that slot and then move the box to a slot, in which chosen the teaser format is not valid? Options for this are
Any further Ideas? |
@EdwardBock But first … how would you estimate the effort to filter the teaser formats based on the slot the box is placed in, within the UI? |
@mkernel @kroppenstedt opinion is also welcome! |
Well, whether it's just the styles or even whole boxes/box types is open for discussion. (Nevertheless, In my examples above box styles read like teaser formats, yeah.) |
Okay … then we do have those Entities that could be limited based on the slot-size …
|
I understand the feature request and i understand that the effort to support all combinations of "available screen estate" and "desired output" (to generalize the problem) is not effective and doesn't help except proving a point (that it works). But: do we really need support in grid for this kind of edge case? There is a preview version of every grid available and every grid editor should (and does!) bring enough taste to the table to "see" shitty layouts. He can already fix the problem by previewing, changing the grid and previewing again. Whatever we're going to integrate is making grid a ton more complex:
Plus: that's engineering madness. Grid doesn't know about these details, so we're talking about hook-hell here. We need a hook to fire from javascript into javascript to tell the editor that a box can't be placed. Another hook to forbid certain box styles on certain boxes in certain slots (or at least the box style - slot combination, which is just a specialised version of the aforementioned hook). Another hook to disable view modes - which is a box-specific configuration parameter. Grid doesn't know anything about view modes. So hooks in custom boxes, it is then. And we need to talk about slot styles to be forbidden for certain slots, right? And what about container styles for containers with more than 3 slots? That's a quite rocky road ahead. And we're not really improving the product from my point of view. So there is a tradeoff: support all combinations in layout OR disable those not supported by implementing the right hooks. |
Proposal
It would be a great addition to Grid if it was possible to restrict box styles to certain container slots.
Motivation
As we are moving to more advanced designs in modern webdesign, some box styles look gorgeous in large slots (think 1/1, 2/3 or 1/2) but look distorted when squeezed into smaler slot sizes.
Examples of this would be boxes with visually stunning imagery or typographic details, which need space to breathe.
Although the goal of Grid is to be as adaptable as possible, and to make every effort to make every box work in every spot on the users‘s behalf, some box styles just don‘t make sense in small slots, and some smaller ones can certainly feel lost in huge slots.
A restriction of boxes to defined slots would give the user valuable feedback what works and what doesn‘t. Furthermore it would allow the designers and developers to focus there efforts on designing and developing the qualitatively best styles, and keeping requirments and complexity manageable, while not having to compromise on subpar box and slot combinations.
Thus such restrictions can help in the paradigm of »race to running software« as it reduces complexity in theme development.
The text was updated successfully, but these errors were encountered: