I have a marquee / "back and forth" effect going (using CSS) that was slowly moving a screen back and forth if the content overflowed the page bounds. I was able to tell whether to enable this effect (and to what extent/at which speed) by calculating the dimensions of the content -- the content itself was pretty static, so this worked fine for a while.
Now, things have changed, features were added, and the content is very dynamic. It will be near impossible to program any kind of quick calculation to determine whether or not any content is cut off. Not to mention what a nightmare this would be to maintain over time.
My question then is, is there a property somewhere I might be able to latch onto to get the same effect? Maybe I can see whether or not the X scrollbar is showing -- if the scrollbar is showing, then enable the marquee animation. Or maybe there is a way I can see the outer bounds (height / width) of the content and compare that against my viewport height and width?
Let me know if I can provide more details about my particular situation that might help.
Still looking for a solution here if anyone has any ideas. It would be great if there were some method I could use on a flex repeater's individual element(s) to grab their x and y dimensions. From there I could do some math to determine whether the elements are spilling off the viewport bounds.
Not to keep bumping, but here's a better idea of what I am after, maybe. If I could pass a view's "actual size" into an output parameter, that would be huge. I have a template repeater with many dynamically-sized elements (basis = auto), and it would be neat to somehow have each element pass its dimensions up into the overarching view.
So in other words, the root of my problem is when I set the "basis" property of something to "auto", I'd like to know the actual size it sets itself to. Possible or not? Leaning toward "not possible" but keeping my fingers crossed...
You might not be getting responses because I think it's still unclear what you are trying to do. Perhaps upload your resources or screenshots that do a better job conveying your problem.
Very possible.
Here are the properties on my flex repeater. Due to the elementPosition and the main basis property both being set to "auto", I lose the ability to know what size they are "as displayed."
I'm trying to grab this "as displayed" size (for either the individual elements, or the main flex repeater -- either way will work for me) so I can compare it against the viewportHeight and viewportWidth.
The end result of this whole ordeal will hopefully be a custom property on my flex repeater with a binding (based on the above logic) that evaluates to True when the flex repeater is overflowing the viewport and False if the entire flex repeater is contained within the viewport.
I'm not aware of any way to get the true rendered size of a view/container - I suspect that info is very hard to get in Perspective, if it exists at all. I'll leave that to others.
Perhaps instead of analyzing those properties directly, you could use a style class with a media query to determine this? As a very rough example, say you have a flex column with a fixed width X and a viewport height Y - a min-aspect-ratio of X/Y would trigger when your column gets too tall (I think - like I said, very rough idea and would need trial and error).
More broadly, this sounds like it could be an XY problem. You're trying to figure out if you're overflowing the viewport, but why? What's the ultimate end goal?
1 Like
I also think this is a good example of XY problem.
1 Like
Overall end goal is the CSS marquee animation -- if overflowing, enable animation. I've technically already solved this problem in a clunky way (by writing x and y values to the size of everything instead of using "auto" for my basis, and then doing a whole lot of pixel math) but I want to find something more dynamic, so I can freely add features or otherwise manipulate the sizing of things and have the logic continue to work without me needing to do a bunch of arithmetic on the backend.
Ideally I would peg this to the scrollbar -- if scrollbar showing, enable animation. I do like that media query stuff, never knew it existed but will give it a try...
This is the Y in the XY problem (the site is pretty sassy/jaded, but you'll get the idea).
In this situation, Y is a marquee animation, ideally triggered by an overflow on screen. X is why you want the marquee in the first place. Could be to alert an operator that the graphics aren't displaying properly and need to be fixed, or that they may need to scroll to view all data, etc. So what's the X here?
With XY problems, it's important to think about whether Y is the right solution at all. You opted for the marquee which worked in the past, but there may be better (easier) solutions. Perhaps instead of alerting the operator that data is off screen, the data itself can be reworked for better visibility. If the view occasionally ends up too tall, maybe it makes sense to add a vertical monitor.
2 Likes
I would agree with this. A scrolling seesaw marquee sounds like you've got a problem you're trying to solve in the wrong way (maybe), but without seeing the graphical content it's hard to know for sure
1 Like
