I see what you mean (I think!?) and honestly, never thought of that.
You’right, it relies on the actual HTML structure … so one has to modify css selectors accordingly … but, since the base html structure hardly ever changes, one sets it up once and that’s it.
I use it with Generatepress, Bricks and Cwicly. Of course, each of these creates a different html structure, so selectors must reflect that … I do it at the beginning and then forget it … no hassle at all.
So, it’s not that one has to modify it constantly … if that is what you meant?
Of course, the ideal solution would be the totally automatic one - independent of the site’s structure, but I don’t know if that’s possible with css only … one just has to tweak/adjust things each and every time to make them work properly.
At least, this is how I see it.
Cheers
P.S. Perhaps Cwicly-team could add this as a feature, a global setting to turn sticky-footer on/off…
If you always have the same and consistent approach to how you build your site, then you are absolutely right.
As long as it’s working for you, it’s a solid solution, which doesn’t differ too much, as it’s quite the same amount of CSS one must add. It’s just not as flexible (due to the nature of how position: sticky; works in general), that’s it.
Exactly. If you always have the same basic DOM structure, it’s just set and forget.
In terms of my provided solution, it’s quite simple though not automated:
Although I would always recommend having header and footer at the same DOM level, it’s not necessarily required with this approach.
The solution you provided requires this specific structure, since the footer always sticks to its direct parent, so there is an actual dependency.
I think that would be quite easy to implement and can see that it’s useful for users.
However, I would always rely on my own solution for more flexibility, also in case I want to add or remove specific styles from this particular rule.
But that’s also rather a thing of being not a fan of such CSS “options”.
Thanks for your feedback over on Facebook @Alexander.
I’m glad you found the solution, which hopefully finds its place in all your future projects.
Just checked your site and works like a charm
In case there is still something unclear, don’t hesitate to reply to this thread.
Here’s what I do, however your mileage might differ.
First the structure of my websites is kind of different from what the Site Editor does by default, as I don’t include site parts in my templates. I’m not sure this is the best approach, however it works for me, and I’m comfortable with it.
By following the structure above, I end up with the following html structure:
With this structure I can use the following CSS in my reset:
body {
display: grid;
grid-template-rows: auto 1fr auto;
min-height: 100svh;
}
What this does is effectively always display header and footer at the top and bottom of the page respectively, and anything in between will always fill the entire available space.
There’s a catch though. For archive templates you’ll have to wrap everything inside a section/container/div (whatever fits your needs), change the tag to <main>, and give it an ID (although Cwicly will probably do it for you if you don’t do it, and handle the skip-link, which is really handy).
This works like a charm form me, and I’m very pleased with its simplicity. Also, the 100svh makes sure there are no jumps on mobile devices.
Semantically speaking there is nothing wrong in terms of HTML structure to have your <main> tag wrapped in a <div> the way I’ve shown. As long as you don’t have it nested inside the <header> or <footer>, and vice-versa (believe me, I’ve checked).
Now, in the literal meaning of the word semantic, it feels and looks off (and some may say wrong). My hopes were that at some point we would be able to change the HTML tag of the .wp-site-blocks element. This would definitely be more elegant and would mean less one level of nesting.
However, something tells me that’s exactly why the Gutenberg team decided to wrap everything inside this element, so you could have them all at the same level or something like that. Probably to allow to not include site parts in templates if we wanted to. But I don’t like this approach. I find having to add the site parts inside every template is counter-intuitive for me, and kind of bloated. Especially since everything always loads expanded in the Navigation panel, and it takes me ages to find where I’m at. It’s not a good workflow for me and my dyslexic alter ego. So I came into terms with having this not-so-optimal structure. I’m fine with it.
But if you don’t like it, you could definitely apply the same CSS to .wp-site-blocks if you wanted to.
