|
N.Z.'s Champion posted:If the element is an <img> or <canvas> etc you can use CSS object-fit to format it like a background image (contain, cover, etc.) to fit the container. Another approach is to size with a CSS unit that's the same horizontally and vertically (ie vw or vh but not both) so your code might look like <div style="width: 5vw; height: 5vw">...</div>. I'm guessing the hacky approaches you've found are those old padding-bottom-based approaches and yeah, I don't like those either. So what I'm aiming for is *either* the container object being sized to available space and both canvases expand-centered into it, or the container object being expand-centered into *its* available space, and the canvases just 100% sized. Though actually, now I mention it, I'm already doing dynamic width= and height= on the canvases based on the size of the parent, so image-style scaling might work, if you can do object-fit at the same time as position: absolute/relative. (Or, since I'm doing dynamic sizing anyway, I could just plain set the position and size for those ones.) The worse case is trying to get a grid of 7x3 squares to appear in one cell of a parent grid, scaled up to the biggest size that fits, while not spacing out the contents. i.e. code:
|
#
?
Apr 10, 2024 01:35
|
|
|
|
| # ? Apr 20, 2024 06:34 |
|
|
Hmm could you combine the canvases? ie make a single composition canvas draw ctx.drawImage(otherCanvas);ctx.drawImage(anotherCanvas) in your requestAnimationFrame render loop, and dispatch events to offscreen/unmounted canvases Then with a single canvas I'm guessing the sizing problem would be easier
|
|
#
?
Apr 10, 2024 05:26
|
|
|
N.Z.'s Champion posted:Hmm could you combine the canvases? ie make a single composition canvas draw ctx.drawImage(otherCanvas);ctx.drawImage(anotherCanvas) in your requestAnimationFrame render loop, and dispatch events to offscreen/unmounted canvases If I inspect the grid I can see that the cells are the expected shape, but I just cannot get a rectangular cell to contain a centered square child element scaled to "fit". (Current state: I gave up and just put a scaled-up rectangle in the cell then bound the size of that to some variables and bound calculations on those variables to top, left, width and height of the child element, which gets it right but fucks up the first frame.) Edit: Extra fun - I had a grid in a grid cell where both grids were width:100% height:100%, then I scaled up the window, they would grow as expected, but if I then shrunk the window (still bigger than its original size), the grids would end up outside the bounds of the window - I think the inner grid forced the outer grid to stay "big", which in turn kept the inner grid from being scaled down because it was scaled to 100% of the available size, which didn't shrink because... roomforthetuna fucked around with this message at 05:39 on Apr 10, 2024 |
|
#
?
Apr 10, 2024 05:35
|
|
|
I would have answered a couple days ago but I was on the road, but this does what I think you were asking for. There's a resize handle on the blue container div to resize it to test the behavior.
|
|
#
?
Apr 10, 2024 21:37
|
|
|
biznatchio posted:I would have answered a couple days ago but I was on the road, but this does what I think you were asking for. There's a resize handle on the blue container div to resize it to test the behavior. (Bit of weirdness in there, the chessboard-grid is somehow sometimes 1 pixel "down" relative to what should be its constraints. I guess the translate -50% operation does its math not quite the same as the left/top 50%, maybe resulting in rounding the other way.)
|
|
#
?
Apr 10, 2024 22:57
|
|
|
roomforthetuna posted:Nice, thanks, that looks like it does the trick, even with nested grids involved. https://playcode.io/1831865 I do see that behavior at some zoom levels. It's a result of the layout calculations working on floating point pixels which get snapped to whole device pixels during rendering; and I don't think there's any good controls in CSS for avoiding it. But it's easy enough to hack in some more precise custom layout logic instead; but it does require some Javascript. edit: Or a more efficient, but more complex version. biznatchio fucked around with this message at 04:08 on Apr 11, 2024 |
|
#
?
Apr 11, 2024 03:26
|
|
|
biznatchio posted:I do see that behavior at some zoom levels. It's a result of the layout calculations working on floating point pixels which get snapped to whole device pixels during rendering; and I don't think there's any good controls in CSS for avoiding it. Related but changing topic, Svelte has some magic css animation support that tries to do a smooth positional animation when you change the location of a thing (e.g. as in this tutorial - click solve then some of the todo items to see what it does easily); I'll be super impressed if it manages to perform a clean positional animation when the item gets repositioned between totally distinct multilayered layout monstrosities. But it seems like it might do it, since the things it's positioning between in that tutorial don't have any direct relationships. I'm curious whether I'll be able to persuade the css animation automation to do the high-math animation technique I previously implemented in flutter (I might have done it in js as well, I don't remember), as some sort of custom easing - the effect I wanted was to animate based on *maximum acceleration* rather than merely easing between positions. A simple example difference is if you moved an item from 0 to 100 it would accelerate until it reaches 50 then start decelerating, just like an easing curve, but then if, for example, when it's at position 25 in that animation, you reset its target position to 25, standard easing-style animation would just make a new curve, say "it's already there" and you'd get a janky sudden stop. My animation goes "the new track is starting at 25,0 with velocity n,0, so it has to decelerate first", then recalculates the subsequent curve from where it will be when velocity-x equals zero - each animation consists of one to four curves depending on how many stages it has to do to smoothly stop at its destination. (It also tries to get the motion duration to be equalized so x and y fully resolve at the same time, because if you just animate x and y independently then you get stupid arcs instead of straight lines.)
|
|
#
?
Apr 11, 2024 05:20
|
|
|
|
| # ? Apr 20, 2024 06:34 |
|
|
vite-node is pretty awesome for running Typescript stuff that's in the middle of a huge rewrite. I've been going over some old codebase, commenting out top level calls and doing broad variable name, function and type changes bit by bit (and then uncommenting relevant calls), that always left things in some kind of broken state for the Typescript compiler. So I just ran tests with vite-node, which just transpiles things away without type-checking, until everything was done and tsc happy.
|
|
#
?
Apr 12, 2024 19:59
|
|
