I remember some of those conversations but didn’t realise there were issues with Calc using browser height in IOS.
My solution outlined above in my demo was to use %vh margins and absolute %vh heights that all added up to 100% and didn’t use any Calc. I still think a % border or margin is the the most pleasing end result.
Thanks for that interesting article and good news that it is so easy to add if needed.
I checked my most recent Source project and the Computed box-sizing is already border-box, so assume this is a site wide Source setting.
I did not realise this was about Source specifically- I just didn’t want people using complicated CSS or layouts do do something that is built in to every browser
Just been having a look at Source in relation to this. Border box works for a simple, single div container but when the container is built up of different divs with different roles then it (obviously) no longer applies. This is true of the Source Containers but also Sections Pro and Box (and the new one) - and pretty much any other container type stack i have tried with. The border that is in Matthias’s Sections Box example above works but it is applied via a completely different method than what is talked about in this thread. The other mentioned stacks have the same issue with the border falling off the bottom of the screen when a border is applied to a 100vh section. @tav - please advise if I am missing / misreading something.
Hmm…, if I only knew how I could make the Limelight modal close when clicked on a menu link. Since these are no real pages but only anchors this could be a bit tricky, right…? ;-)
These both work as I stated above but they use pseudo’s to position the border due to the layers that are supported by both stacks (assuming the borders child is used for Sections Pro). They have nothing to do with the discussion on the box-sizing model.
Sorry, I don’t know see how roles on a div will affect the box sizing model in use, nor how different divs would affect the behaviour of *, *::before, *::after {box-sizing:border-box}.
Could you elaborate please. (Modify that codepen to break it may be the easiest way to demonstrate it?)
Ok - not breaking then - “issue” I just meant that.
In what circumstances do the other named stacks have the “issue” you describe when the box-sizing is set to border-box? I didn’t think the discussion was about any specific stacks, we were debating whether it was ever necessary to manually replicate the box sizing behaviour with a calc() statement.
If I have missed a situation where this is necessary then that’s fine but I honestly cannot see where it would be required or preferred.
The post started by highlighting that the bottom border in containers set to 100vh in F6 and Source were off the bottom of the screen. The same is true in any other container stack that I’ve tried.
You seemed to suggest that if Containers were simply using border box then all would be good. But all of these containers are built up of different divs to control these aspects themselves.
Well F6 works just fine for me as site styles sets a box-sizing of border-box - see this screen shot: https://apex.d.pr/saNWCU
Yes, I was not suggesting this, I was stating it. If the border is on the outer div and set to border box then whatever other divs are inside have zero affect.
If I am missing something in the CSS spec here then simply modify that Codepen by adding other divs inside get the border box to go outside.
But if the height is applied to an inner div then although the border will work as expected it will fall out of view at the bottom. This is how pretty much every container stack applies a height value.
OK so now we have got to the realms of the ridiculous. Of course if I put another container inside that is bigger then it will push off the screen - that is just technically known as having the border on the wrong div.
I merely stated that the box-sizing model handles this without the need of a calc() statement, I didn’t know this would be controversial or turn into a debate about nothing which I certainly don’t want or really have time for.
The box sizing model tells us how margins (outside) > border > content (inside) will behave and allows us to decide which “side of the line” the border falls.
If a user sets a stack to be 100% of the browser height and adds a border, their expectation is that the border will be included within this height. Setting the height on an inner div and pushing the border off screen is a deliberate act that introduces unexpected behaviour; the height with a border will of course always be different than specified it is just that most times people will not notice.
I am in no way criticising any other stacks and in fact as I said above, I didn’t know we were talking about a stack in particular, I was just pointing out the usual (and simple) solution for keeping borders where people expect them to be. The Source container obviously puts the height on an inner div for a reason that I am not party to. I am not trying to pick faults in this in any way.
With respect, I merely stated a well know and obvious aspect of CSS in relation to a specific case where users were being encouraged to manually add CSS. I believe in this situation they should be encouraged to do things correctly and understand the box-sizing model with which they are interacting. I stand by my advice to use border-box and not calc().
I agree with all of that. It’s not just Source containers where this happens though. I saw the same thing with a Sections Pro and the new version and others. Anyway…
I’ve a van arriving in an hour for my house move. I’ll be away from my computers and WiFi for two or three days so happy to leave this here too.
not when using it with the borders child it doesn’t. There are 1000’s of pages where full height SP’s are used. If you use the default stacks border then things can break but remember that was the case for many stacks from that generation (inline stacks did not exist then and people knew not to use the default controls when alternates were provided)
This is a beta, unfinished and irrelevant - it will work when released I assure you (if I bother to)
Hope it all goes well, house moving makes stacks look like fun :)
The next time I move house it’ll be to Alicante, Spain. No removal van needed as I’m not taking a thing with me. Just me, the wife, my bikes and the dogs. Maybe my iMacs too.
Me, the wife and 2 small kids have been living with my father-in-law for the last 7 1/2 months. This move day has felt like an eternity away for so long.