Closed designerno1 closed 6 years ago
I concur, this is a pretty simple issue, or at least it would seem that way, however, it's a little more complicated due to display:none on those elements. I'll log this under known issues, but, I don't know when I'll be able to get to it. I'll put a help wanted tag on this and see if anyone from the community wants to take a crack at it.
maybe an option to autoHeight per Slide would be great, simple don't set the max-height and height to the orbit elements so the height changes per slide, maybe someone need this
Perhaps, then you get content shifting/jumping though.
yes sometimes you have slider not equal height
Hi guys! I had the same problem but now I solved with this solution (I modified two row (236 and 246) in foundation.orbit.js, here attached)
Try it and let me the result, thanks!
Hi alessandromarotta thanks for this fix, is there any way to exclude the arrows from the auto height adjustment, for cases where the slide heights are different the arrows are currently moving up and down, I'd like them in a consistent position?
Shouldn't the arrows always be vertically in the center of the slide by default?
@alessandromarotta Is this a PR you are able to submit?
Ideally there is a resize listener that is throttled or debounced.
I'm i right or the issue make the orbit un usable after a resize ? Why don't state that .orbit-container is 100% height ?
@ClementVidal That could work but perhaps not if you wanted the slides to all be the same height which is an option. I'd like the arrow height calculation to be taken out of the JS and use the centering mixin instead.
It would be nice if fixed height was a data-[option]
which would allow for varied-height slides.
Another option is to use the same padding-bottom
/positioning method as Flex Video (with a configurable ratio).
@alessandromarotta your orbit fix worked perfect for me...I've aggressively resized my browser window for about 20 seconds and the layout has resisted breaking, so much appreciation. It's disappointing this glitch is still plaguing the current F6 version.
The above solution is not rendering any change to the resizing behaviour of my orbit slider. Is there an update on the status of this?
No need for javascript edits, just add
ul.orbit-container {
height: auto !important;
}
li.orbit-slide {
max-height: none !important;
}
to your CSS and Orbit resizes nicely.
Hey @nitrokevin, did you find a fix to your problem about "is there any way to exclude the arrows from the auto height adjustment"?
When using the Orbit Slider and you want to remove the navigation arrows add the data-options attribute data-nav-buttons:false;
to your <ul>
tag.
For example, <ul class="slider" data-orbit data-options="data-nav-buttons:false;">
Hope this helps.
Hey @ooksanen, I've found a similar solution to fix the auto-height issue with the Orbit Slider.
.orbit-slides-container{
height: 100% !important;
}
.orbit-container .orbit-slides-container li.active{
position:relative;
}
Here is a link to a pen for those still having the auto-height issue.
@alessandromarotta I couldn't seem to duplicate your solution. When using the js/foundation.orbit.js
file isolated from the CSS above, there seems to be something else overriding it. I think it may have to do with using https://cdnjs.cloudflare.com/ajax/libs/foundation/5.5.2/js/foundation.min.js
in conjunction. Removing the js/foundation.orbit.js
file from my scripts and relying on https://cdnjs.cloudflare.com/ajax/libs/foundation/5.5.2/js/foundation.min.js
and the CSS above, the slider auto-height works.
Any feedback would be greatly appreciated :)
@Jflem1290 can you submit your fix as a PR, and we'll run it through some review and testing?
I discussed this with @Jflem1290 off line, and it seems like we have an outstanding question - In some situations, we want the Orbit slider to be automatically resize (in which case it seems like a CSS solution is sufficient), and in others we do not (in which case we need the JS... and there may still be a bug).
The question I have is: What should our default behavior be? Should orbit by default auto-resize or no?
cc @designerno1 @rafibomb @andycochran
The question I have is: What should our default behavior be? Should orbit by default auto-resize or no?
I think the default behavior should be auto-resize. This is how most responsive sliders work and how (I believe) Orbit worked in Foundation 5.
I also think the default behavior should be auto-resize. I solved this (in 6.2.3) using a function that resize the orbit-slide to the current slide and called on slidechange event. To have nicer transitions for images with different heights i added a beforeslidechange event https://github.com/zurb/foundation-sites/pull/9141 and animated (jQuery) the change in height. Animating height changes after the slide transition looks less pretty.
btw orbit-slide resizing needs to be called on window resize event too.
@ooksanen solved this problem that happens since fn 5.x thinking simple. I had similar problem, using orbit inside tabs. In inactive tabs, orbit starts with height 0. Using your fix, this problem is fixed too. Thanks a lot dude =)
@ookansen That helped with an issue I'd been having with orbit not working inside slides.
Anyone have an opinion on whether @ookansen or @Jflem1290 's css solution is preferable?
Fixed my issue too, thanks @ooksanen. As for a preference tomhicz, they both work, always good to keep all options in your css bag of tricks and workarounds ;)
@trakker @tomhicz @ooksanen @Jflem1290 I took a pass at fixing this for real in #9317, would love it if you can take a look and see if it addresses your issues.
I am getting this issue in 6.3.1 when viewing the orbit on iphone safari browser only. Other platforms are ok. The snippet posted by @ooksanen fixes the issue, so this bug is still present.
Thanks for the report @matthewhegarty, reopening this.
I am working on a Portfolio widget with the modes "Modal", "Card" and "Orbit" based on Foundation 6 for inclusion in user webpages created with Hubzilla, a decentralized and privacy respecting publishing solution. The idea is to allow an automated and hands-off portfolio for painters, photographers and other artists, with flexibility for web developers. I am nearly done, so this will be included in Hubzilla 2.6.
However, I am having some trouble with Orbit height.
Users upload their images to one or more albums with WebDAV using something like the FolderSync app on their phone or tablet, a file manager with such support or command line rsync, or simply manually uploading through the web interface. Albums are access controlled, the Internet, some group, my friends, only me and so on. Upon upload, Hubzilla will automatically create four sizes - size 0 or Original size available from the file system, while size 1 large , size 2 medium and size 3 small are in the database. Widgets are created using PHP and Smarty3 templates, then included into blocks and regions in layouts using a page description language called Comanche, and then finally the layout is attached to user's webpage.
The Portfolio widget takes three parameters - album, album title and mode, either Modal, Card or Orbit. Since I cannot know how each instance of the Portrait widget is used at different Hubzilla sites, I am going by the assumption images can have any width or height, and these will be square, landscape or portrait, probably all three in the same album.
Modal is done, the widget fetches images from the chosen album, displays them as thumbnails and when you click them you get fullscreen mode - this was very easy with Foundation 6 - thanks.
Card is nearly done, for some reason card-border and card-shadow seems to be missing - any help on that would be appreciated. Otherwise, quite easy.
Orbit has been the most difficult to get right, and I have not done the buttons at the bottom yet, need some more Smarty3 foo there. The W3 validator also complains about buttons inside UL and the figcaption, but it works.
I seem to have a handle on square and landscape images - needs some more grid understanding on my part to tweak just right.
However, portrait images mixed with square and landscape images are not handled well at the moment. An example is available at https://zot-mor.rhcloud.com/page/art/thatsimpossibletoo . May be #nsfw in your country (one arty 3D drawing of nude pregnant woman praying made with Makehuman and POV-Ray).
In the example page, all images are Hubzilla size 3, i.e. the small version. There is one tall portrait image, and Orbit seems to be confused about the height of the entire slideshow, taking the tallest image as its reference (?). The result is the other images are distorted and scaled into a blur.
What I would like to happen, is to be able to set a height for the slideshow using the Foundation grid, have the image height not be higher than the slideshow, and preferably scaled correctly. Is this possible?
Still experiencing this issue in 6.4.1 on mobile. Present on Chrome, Firefox, and Safari --> iPhone 7.
resizing does not work reliably and it seems the images are hidden / not showing after a resize. Is there a fix / workaround?
Could solve it with Foundation.reInit('orbit');
CSS fixes above don't work. The content shifts on sliding, especially sitting in a padded container with no height set. I'm using text for my slide content. Slides will cut off content. Looks like Orbit isn't able to accurately determine the height of all the content in the slides.
@richiesun did you ever get a fix for this? Experiencing the same issues with text cut off at first then resizing bluntly.
Have tried adding transition to the height but makes no difference - would be nice to have the container resize smoothly before displaying the slide content.
@patrickwurk I switched to Slick Carousel. Took minutes to get that going with no issues. Had 3 carousels on one page. Orbit is not production ready. I'd switch if I were you.
@richiesun oh wow. Slick is mostly unmaintained. Take a look at the open issues and how the last releases were done.
Try Swiper or something else which is more robust.
The deleted Slick 1.7.0 and 1.7.1 (and probably 1.8.0) releases of Slick broke our websites.
Was trying to keep everything in Foundation but just used OwlCarousel 2 instead took about 5 mins to replace the Orbit slider so happy days. @richiesun @DanielRuf Thanks for the responses - will give Swiper a go next time looks simple as well and well maintained with many options so thanks for that.
Closing this. We can address this in V7.
Swiper has autoheight, see demo at https://idangero.us/swiper/demos/390-autoheight.html
and code at
https://github.com/nolimits4web/swiper/search?utf8=%E2%9C%93&q=autoheight&type=
@HaakonME sure, but this issue is about Orbit.
@DanielRuf I know :-) Hubzilla uses Foundation 6 and I am writing a new widget using Orbit, see previous lengthy comment. I noticed fixing autoheight / autowidth in Orbit has been postponed to Foundation 7 and was in need of help, so I thought I would help out by pointing to a resource where this issue is fixed already.
by pointing to a resource where this issue is fixed already.
Any help is very appreciated. How did you solve it with Orbit and could you show us the needed steps and changes? Would be great to create some PR together.
Unfortunately, I have not solved it. I was hoping the maintainer of Orbit would look at how Swiper did it and adapt it to Orbit.
Hubzilla's Portfolio widget can be added to a web page as many times as needed. The widget takes an album and a mode as its main arguments. The mode can be Modal, Card or Orbit. You can see Modal in action at https://elsmussols.org/page/parlehaakon/thatsimpossibletoo . At the same URL, my Hubzilla friends see different page content, including the modes Card and Orbit in its current state. I had to stop working on mode Orbit, because my aim is allow Hubzilla members to just sync images from their phones and have them automatically display correctly - sync and publish, but since autoresize does not work yet, mode Orbit is still incomplete.
https://github.com/nolimits4web/Swiper/issues/1132 shows how they found and set the height for the current slide two years ago. They looked at the active index. I am on my phone for a couple of days without access to my computer.
I was hoping the maintainer of Orbit would look at how Swiper did it and adapt it to Orbit.
Which are we and we are also contributing our free time to fix issues.
Forcing height: auto with css might help.
@ooksanen's answer might help.
But still, we'll solve this in v7 and there is no PR at the moment.
Your slides images probably use no max-width: 100%.
PR = Problem Report, right?
v7 it is then.
Thanks for looking into it!
PR = pull request Issues are bug reports.
10-4
max-height and height should be recalced on resize or there should be a funktion to recalc it _prepareForOrbit() does not work for me