Some real problems with height

[benchub]

On https://bracketry.app/create-bracket/#problem-of-height, you list some problems with height and sizing. Sadly, when I go look at this page in any Safari browser (mac os or iphone), the problems are worse than you describe - as soon as bracketry detects me scrolling on that example, every few seconds bracketry keeps redrawing things to be stretched vertically further and further apart. Looking at this page with Firefox and Chrome have no such issues.

FWIW, in testing this on my own test case (https://silentmedia.com/bracketry/), the problem seems to manifest only when the entire width of the bracket doesn't fit in the window. If the window is wide enough to contain the full bracket, then vertical scrolling has no terrible effect.

I can hide this problem by setting the height of the enclosing element, as you suggest, but then we have a different problem: when I use setBaseRoundIndex(), then the bracket defaults to viewing the vertical top of the bracket, even though the actual information might be far below the bottom of the window. This is terribly confusing to users, and again, this problem only manifests on Safari - on Firefox and Chrome, bracketry will show the vertical middle of the bracket on the defined base round index.

[sbachinin]

Thanks for opening the issue.

1. Height begins to grow after scrolling in Safari.
   I can see it on my Iphone. Apparently something is wrong there and I will look into it asap.

2. setBaseRoundIndex resets the bracket to the top of its content in Safari. (If that's what you mean).
   This I can't reproduce.
   I'm trying it on "External navigation" page where setBaseRoundIndex is used to switch between rounds and it works fine in all browsers. (I mean that if bracket was scrolled down to somewhere in the middle, then after switching to another round I get an approximately same vertical part of the bracket).
   So it would help if you provide a working example on your site or in Codepen or elsewhere.

Also I'd like to know more about your requirements.
If I understood you correctly, you were trying to make a bracket without fixed height, that is, it changed its height whenever you switch to another "base" round.
Is such behaviour ok for you from a UI perspective? I assumed that it's the "wrong way" because having such a big jumping element on the page can cause many problems. But I might be wrong.

[benchub]

Hey Sergei, thanks for the quick reply. (And thanks for making bracketry - it's pretty great.)

In more testing I think I was wrong about #2. I'm not sure what I was seeing before, but I'm not able to repro it now.

My end goal is a to make a bracket that fills the screen, whatever that might be - hence my biggest problem (Safarai and growing heights when no fixed height is specified). This works really well on Firefox and Chrome. In my use case, it's going to be pretty rare to look at previous rounds before the one I set with the base round, so if that UI is a little janky I'm ok with it.

[sbachinin]

Well, "fill the screen" can mean different things.
I assume that you were trying to make the bracket

1. as wide as the viewport
2. at least as high as the viewport.
   And you solved that by having fluid height.

Such solution seems to me problematic in many ways, for instance

• If height is fluid, then it can become less than the viewport height (in case that only few last rounds are displayed).
• It will be anyway difficult (or impossible) to maintain a proper scroll position when switching between rounds.

Making things "full viewport" might be a tough challenge, from my experience. I mean, not only with bracketry but in webdev in general.
I tried hard to build a "full viewport" mode into bracketry as an optional behaviour and gave up, I don't remember exactly why but mostly because of unstable viewport height on mobile screens where browser controls can appear and disappear.

I don't know your browser/device requirements but anyway try this example - how far is it from what you need? And does it behave well on various devices that you mean to support?

This example forces the bracket to be exactly the viewport height by setting "100%" heights in css.
I think it might be a good solution - but only if there is nothing else on the screen, and so the page is not scrollable.
Code of this example is here.

[benchub]

You are correct in all your guesses. :) I was indeed trying to show as much of a tournament as a user's screen would allow. I do like your full screen example, but I have a menu bar and a footer I want to maintain, and a little text between the menu bar and the top of the bracket, so I gather it won't work for me.

Anyway, I think the fluid height works great as is today in Firefox and Chrome. It's just Safari that is being problematic, and it sounds like you're on that.

[sbachinin]

"Growing height" in Safari is now fixed. At least it looks ok to me.
Soon it will be released.
For now you can use this bundle. It's an ESM bundle so it has to be imported like import { createBracket } from "./path_to_bundle"

I have limited access to macOS / iOS devices so it'd be great if you try it. (You can also just visit an auto-height example page in Safari).

Note that I will probably disable this "fluid height" behaviour in later versions.
That's because I still don't see any reasonable use cases for it. (And I also see a lot of confusion about this behaviour).
In your case I think you can achieve what you want by just setting something like { height: 100vh } on your wrapper element or by providing the similar height option to bracketry. Or you can use svh units so that the bracket was guaranteed to be no higher than the viewport.

[benchub]

Confirmed, your example page works correctly in Safari. Thanks!