OneZoom
Variable-size carousel pictures
The mock-up has the central image in the "popular places" carousel / slider larger than the surrounding ones (see below). @lentinj looked into this and it wasn't clear how to achieve the effect. I asked on the UIkit discord forum, and got the following reponse, which implies it should be possible to style in this way.
@ yan i would combine slider -> slide set + content parallax (https://getuikit.com/docs/slider#slide-sets + https://getuikit.com/docs/slider#content-parallax) should be possible
The actual sizing is fairly easy, using transform: scale(..). As the scale gets applied post-layout, this gets us the overlap too. Nice. The problem is element ordering / stacking.
By default, later (HTML-wise) elements stack on top of previous ones. So you could in CSS say that the second item is scaled larger, third scaled larger than that, the fourth scaled smaller and underneath the third, etc. There's 2 reasons this didn't work:
- We can't work out the "middle" in CSS for a generic number of items easily. Although one could probably keep heaping on rules until it worked.
- The wrapping of the carousel means you can't rely on the items being in consecutive order. You'd have to have another lump of CSS rules that handled when the carousel items were split in 2. And you can't select on
order: -2, since that's a CSS rule not an attribute.
Here's me ripping out the dregs of this attempt:
https://github.com/OneZoom/OZtree/commit/3bc79ef9a7b4e55674db80003176fef04249c15e
I did see content parallax, but I couldn't imagine it helping; we have transitions between although in retrospect it would help neaten the transition to a hidden item.
I think the way to solve this would be to have a javascript function that listened to one of the carousel events and juggled CSS classes around for all uk-active items, center, center+1, ... then the CSS rules become easy. (if only I thought of that at the time...)
Another issue here is the transition, the easiest thing is to shuffle them and let the z-index update at the end, but it's a slightly implausible jump---everything moves, then suddenly the topmost item jumps to the top. It'd be worth delaying the z-index transition (possibly using transition-delay?) so the swap happens mid-transition where (hopefully) the old and new centre item are the same size.
@lentinj: I asked on the UIkit discussion list and they very helpfully said it should be possible to "Use Slider content parallax to scale items". There's a pen now up at https://codepen.io/zzseba78/pen/GzrYJE . I could try implementing it, but if you think you could do it in an hour or so, maybe this could be added to your list?
That example only has one active item, so isn't very interesting. Like I said above, the sizing that parallax offers isn't the hard problem to solve. We have an arbitrary number of active items (depending on screen width, 3 in your example above) which need to be stacked and scaled based around the centre active item.
(the other way of looking at it would be that the kingfisher is the only active item, and we have multiple layers of inactive items. But that is even further from what ui-kit supports)
But I could have a go at plugging the gap with javascript to generate "center" classes as I suggested above. That shouldn't take too long to try.
Oh, sorry, I must have misunderstood. Don't worry if it is likely to take too long: it's only a "nice to have".
@hyanwong b6a4a9d attempts this. It's a bit clunky and not all the elements are sized yet, but it's a lot closer to something working.
The reason for the jumpy animation is ui-kit's slide process is "show new item, slide, hide old item". We need to ideally know the final set of items before the slide, so we can let the transitions do their thing whilst the sliding is happening. You could potentially work around it by assuming that the other end will be removed, but that was fiddly code I run out of time for.
The other option is to see if ui-kit people are interested in parallax scrolling that does what we need with multiple items. But I'd guess that isn't easy.
Looks good - we'll be using this code in the front page and will follow up with ui-kit later to try and improve
In some cases the images are all the same size when the page loads for the first time and they only resize in the desired (variable size) way when the carousel is interacted with by the user. If I clear caches and reload the page the issue often doesn't recur - which makes me suspicious that there is a synchronisation issue here where the resizing is occasionally called before the carousel is fully initialised.
In some cases the images are all the same size when the page loads for the first time
Yes, you've spotted this bodge:
https://github.com/hyanwong/OZtree/commit/413ef51293a33384f8c8a33b9f7c6f32e10dfc9d#diff-e926f4476fdb03d0714ad2b7c90f75aaR104
itemshown doesn't trigger as UI-Kit is setting itself up. There's probably a generic "This component is ready to go" event, but I hadn't found it in time.
Another comment on this - I've noticed that when the front page loads, the carousel pictures load before any other content - then the rest of the content loads. I wonder if this is related to #341
labelling as a priority but it's probably the lowest priority of the priority flagged items.
Not a priority any more - we may rethink the UX of the front page a little to accommodate tours and that's the time to revisit this issue. leaving open but un-assigning Jamie to help focus his time.