Possibility to alter values over breakpoints upwards AND downwards
-
“Mobile first” is the established pattern for responsive web design and progressive web apps.
Greenshift on the other hand defines it the other way round, a “Desktop down” design approach. A block’s attribute by default is valid for the maximum breakpoint (Desktop) and all lower breakpoints. Then for lower resolutions you define the layout/style deviations. Or set values to a concrete value which on Desktop were unset (empty field).
- It is somehow ok to adapt oneself to that design workflow.
- But could you make it at least possible to also work the other way round, when one needs it?
Problem and proposed solution (4:52 video with audio):
?? Possibility to alter values over breakpoints upwards AND downwards Concept as text
Let’s say that I define my block source order (in the document outline) like this:
headline
img1
p1
img2
p2
img3
p3Then a web spider, a terminal web browser “see” them in a continuous stream and on mobile the user sees it pretty much that way too, all stacked above each other. If no flexbox or css-grid order attribute gets applied, then exactly as in source code order. That’s ideal, the semantic most truthful representation. But on higher breakpoints other presentation orders would be benefitial for the P blocks which describe what’s going on in the corresponding IMG blocks.
On MobileLandscape+ I want it:
headline
img1 p1
img2 p2
img3 p3On Desktop I want it:
headline
img1 img2 img3
p–1 p–2 p–3So I could easily achieve the spans by setting the headline column start to 1 and end to -1 to always span full width and setting the grid-container to 2 columns for MobileLandscape+ and 3 columns for Desktop. Easy cheesy.
But I want to also achieve the custom order for MobileLandscape+ with minimal editing effort, especially that you recently added support for negative order numbers too. Hence I wanted to do this:
Those native IMG and native P blocks are each are wrapped in a Greenshift container block acting as a grid item in their parent grid-container (because so far the Greenshift Image block and Advanced Text block do yet not have grid-item controls which would spare me that wrapping).
On Desktop I give those grid items a custom order which is different to the source order.
Then on MobileLandscape I wanted to erase the order num-field, and hoped that this sets the value on MobileLandscape to “unset” and in consequence also to all other breakpoints below that.
But sadly that’s not possible. Greenshifts’s business logic seems to insist strictly only a “Desktop down” design approach, and there is no workaround.
Could you consider to allow that an attribute can get a value, and on a lower breakpoint if you delete the value it is unset for its own breakpoint and all lower breakpoints, unless a lower breakpoint again sets a value?
Because without this you are forcing your users to BAD practices regarding semantic HTML and SEO:
- I need to make my HTML element source order like presented on Desktop (which in some layouts is NOT as a spider should see it!) and have the order attributes empty and give the smaller breakpoints their concrete values.
- A lot of extra effort.
- And bad code/semantics.
I hope that you will make this other approach possible. A concrete or null value should be possible all breakpoints downwards OR upwards until it encounters the next breakpoint with a concrete or null value.
-
A Mobile first workflow within the Desktop Down paradigm of Greenshift is almost impossible because a concrete value set at a high breakpoint cannot be set to empty (aka NULL aka UNSET) for a lower breakpoint and to all further lower ones. Again the video from my first post:
?? Possibility to alter values over breakpoints upwards AND downwards Somehow efficient solution with Greenshift’s Desktop down paradigm that I found today:
?? Responsive grid item order with the Desktop down approach It’s still a bit less efficient: I need to set the grid items custom order numbers for 2 breakpoints instead of having grid item order numbers undefined in all breakpoints and only set them custom per 1 special breakpoint. But at least some improvement.
- Set the block source order as ideal for SEO machine consumption, Screen Reader (blind people!), Terminal browser, Mobile fallback. That was crucial to me!
- Then on Desktop select all blocks in the Inspector all give them a very high column order number, e.g. 1000. That way you still see the source order as of now, and when you renumber in the next steps, the latest element that you change to a relatively lower number (0-100) will always be above the yet untreated elements (all having ordinal number 1000). That way you are less disoriented during the process!
- On Desktop per each grid item set a custom column order number. Leave some number gaps for maximum freedom with breakpoint customization. E.g. Encode row-nr into the first 1-2 digit(s) and col-nr into the second 1-2 digit(s) thereafter (like accountants, librarians, keep stable+flexible number series).
- On Tablet per each grid item another adequate column order number. Often this alone then works fine for all lower breakpoints too.
? Then the only thing which varies per breakpoint is the grid-container’s → Flexible content options → Columns number (btw that’s bad English, better would be: “Column amount” or “Amount of columns”).
? And the order numbers will be alright as long your elements move along a regular zig-zag pattern.
As I showcased I can arrange myself with the “Desktop down” approach.
Still I made a concrete proposal for how to keep that approach but nevertheless add a bit more design flexibility and efficiency:
Could you consider?to allow that an attribute can get a value on a certain breakpoint, and on a lower breakpoint if you delete the value it is unset for itself and all further breakpoints downwards, until the next breakpoint with another concrete value value?
What do you think about that? Is that possible from your logic architecture behind and from the logic for the controls?
The breakpoint logic as it currently is plus the changes I propose to add in an explainer video with audio (4:55):
?? Possibility to pass concrete or null values down By help of that scale from the video above I realized that media queries can only be designed to inherit in one direction: From UP in case of a Desktop down paradigm, or from BELOW in a Mobile First paradigm.
<> 10 <> 20 <> <> Desk Tabl MobL MobP BP-X BP-YMobLif allowed to point in both directions in case of conflict/fallback needs a preferred lookup direction, which is equal to just set up one lookup direction in the first place.
- Further this would have an undesired/ worsening aspect:
Deskwhich is NULL by default in this case would inherit fromTablas soon as it is set to a value. Certainly undesired!
But still my proposal from the posting above, which adheres to the Desktop down paradigm, would still ease things.
Now all options and all underlying logic was presented. Time to decide. Looking forward to your answer!
To clarify a possible misunderstanding: My proposal does not force the user to set 2-3 breakpoints. It makes it possible, but does not enforce it at all.
- You can set Desktop to X. → All lower breakpoints inherit X.
- You can set Tablet to X. → Desktop has the default value. Everything below Tablet inherits X.
- You could set Desktop to X, and Tablet to Y. → Everything below Tablet inherits Y.
- New possibility: You could set Desktop to X, and Tablet to NULL. → Everything below Tablet inherits NULL.
- New possibility: You could set Desktop to X, Tablet to NULL, Mobile-Landscape to Z. → Mobile-Landscape inherits Z.
The only real change I ask for is the possibility to add an explicit NULL value to a single breakpoint. Which then gets passed down as long until there is another concrete value. Is this really not possible?
- On a media-query level I’m quite certain this is possible.
- Greenshift’s UI controls of course would need to introduce a visualization of a user assigned NULL or UNSET.
- But overall I think it is possible. If you would explain to me why this is not possible I sure accept that! But I still think there is a misunderstanding. That’s why I try and try again to explain my idea. Hope that you now get the idea. Or that you explain me the exact reason why this is not possible.
- The topic ‘Possibility to alter values over breakpoints upwards AND downwards’ is closed to new replies.
