I’ve been noticing in a couple of builds that I am having to re-arrange the order of the elements in the Client First Core Structure Strategy to be able to build more complex layouts.
In the Client First Documentation, the order is padding-global, then container-[size], then padding-section-[size].
I have instead been placing container-large last as a child of padding-section-[size] to allow for a section having elements of different widths.
For example, in the below gif you can see I have a layout where the heading and the instagram handle/link should be aligned with the rest of the page’s content, so they should both go inside container-medium. However, there was also a full-screen photo gallery in the design. So in this instance, I placed a container-medium above and below the photo gallery so that the text would be aligned with the rest of the page’s content and the images would be full-screen.
In this second example, the design called for a decorative background image that was wider than the alignment of the main content. This background image could not be a background image of the section div because it was not meant to be full-screen width. The best solution I could find was to again have two container-[size] elements as children of padding-section-small.
Part of the reason Client First is so useful is that a developer could come into another developer’s project and understand everything easily. However, my projects are now inconsistent. Most sections follow the order displayed in the Client First Docs: padding-global, then container-[size], then padding-section-[size]. However, some sections have this re-arranged order to allow for elements of different widths within the same section. I believe this makes the project more confusing to make sense of unless explained.
So my question here is: is there a better way to do this where the project can both comply with Client-First and maintain consistency?
And could Client-First be updated with a re-arranged order to eliminate this issue?
Having padding-section-[size] last in the order has little advantage. This is because the utility of this class is so that you could come into the project later and adjust the vertical padding between all sections at once if the client wanted more space between sections after the project was built. It makes for quick and easy editing of the whole page. However, if you had multiple instances of padding-section-[size] within the same section, then when you adjust this class you would be adjusting the padding within sections as well as the padding between sections. So there is little use in having multiple instances of padding-section-[size] within a section and therefore little advantage to having it last in the order as this flexibility is not required. It would be more useful to simply adjust padding on the custom classes within the section if more internal padding was required.
However, as I hopefully illustrated, there is an advantage to having the container-[size] class last in the order because then you can have multiple containers of different sizes within the same section, or you can choose to place some content (like full-screen content) outside of the container-[size] class and the rest of the content within it. Then the container-[size] classes still maintain their utility. After the project has been built, if the client wanted the main content to be wider/narrower, you could still edit these classes, affect the whole page at once, and have no unpleasant consequences of doing so.
The client first docs mention there is flexibility in where you place padding-global, but mentions no such flexibility for padding-section-[size] or container-[size].
All of the Finsweet-made Client-First templates/cloneables seem to utilise a naming convention of [identifier]_component to signify the div which contains the main content of a section. As far as I can tell, the order which allows for the most flexibility would be to actually place container-[size] classes within that.
This way you could lift that component class out and copy/paste it elsewhere and the container-[size] classes would continue their purpose of maintaining the widths of the different elements. As far as I can tell, this order would be more beneficial as each class maintains both its layout purpose and its post-build utility while allowing for flexibility of widths and allowing for easy copy/paste components.
I also believe that padding-global would be better placed inside of the [identifier]_component div because then full-screen content could be placed outside of this. Then post-build editing of padding-global would affect all of the page’s narrower content and leave the full-screen content in-tact. This would allow simple sections to be as simple as they were before, but complex sections can now be built with flexibility and follow the same consistent order.
Given that [identifier]_component is already a class present in the structure of all the Client-First templates, this solution adds no new classes or complexity, it only re-arranges the order of them for added functionality and flexibility.
This order would have a logical division between classes that deal with distancing between sections and classes that deal with distancing within sections, separated by a copy/pasteable component class.
Let me know if you think I’ve misunderstood anything or if theres a better way of doing this. Thanks for any help!