Hi there @ Laborator,

... as descriptive as possible? ... OK!
It's a longer ticket that targets development level.

The display of artworks is the core of our project and it's been the elegance of the 'Adestra' fullscreen portfolio view that made us choose Kalium. However, we ended up 'abusing' the Carousel view with only a single image per portfolio item because we needed sepearate control of foreground and background ... and the most elegant item description in the lower left corner that isn't available in any other view (but Fullscreen).

Several issues came to light when we began to take a closer look at responsive behaviour. We address large and x-large displays as well as tablets. I hope very much that we can come up with some kind of solution or workaround for the status quo, that I would summarize as follows:

1. Most unfortunate, image width depends on the viewport and not on the container. While the container is designed in static ranges (from breakpoint to breakpoint), the image size floats and the „waste of unused image display space“ on 768px plus wide screens reaches from less than 10% to a wooping 40%. On smaller screens below 768px image display is 100% viewport width and exceeds container width. (Sample1_768vs767.jpg)
2. A large padding of 300px prevents image responsiveness, because large images are loaded to fill small spaces.
3. The 'Maximum Image Height' (MIH) feature has all kinds of effects, i.e. with a value that reqpresents the original image height, the image can be cut off (sample3.jpg). At the „-1“ setting, an image gets approx. 5000px wide.

Potential cures?

? Introduce in-between viewport ranges in custom css and target the 150px padding of the image container (slick-list draggable?) to reduce the waste of space factor. Then turn on „Image Spacing“ in Carousel settings, that adds padding of 15px to prevent views below 768px from touching the screen border. (Sample1_768vs767.jpg)?

I'm happy to test your code suggestions and I would realy like to stick with Kalium. In the long run, perhaps Laborator could come up with a reworked carousel or even a new and cool, responsive, image centric portfolio item … hey, it's a „creative“ theme!

Below are more details from my „reseaches“.
Looking forward to hear from you
Wolfgang

-

To see, what's actually going on, I created the following 
TEST SETUP
Graphpaper image: 'Rect' 1600 x 1200 px 
The versions created by WP 4.7/Kalium 2 Media Library import were fetched via FTP from the WP content directory, got their dimensions written „inside“ and were then re-uploaded via FTP. As a result, you can see, where and under what viewport/browser dimension which image version is displayed.

In addition, a 1920x1200 graphpaper background image is center fixed auto-sized and gives a stable 1:1 pixel-ratio reference.

FINDINGs 
(Findings.jpg)

• ?@768, the container width is static at 750px, 
• @992, the container width is static at 970px and 
• @1200 the container width is static at 1170px.

The image holder (slick-list draggable?) always follows the viewport width 1:1.

However, 

• above @768 a padding of 150px (total 300px!) is active, while
• below @768 neither padding nor margin are in place (zero!).
• Both has considerable side effects (SFX).

Above-SFX:

The image related responsiveness built into Kalium is shifted off target (could say: mislead) by the huge padding.
@1200 (+x) the 1600px image version is loaded and displayed 900px (+x) wide … hm, OK.
@1117 the 1600px version is still loaded and displayed 817px wide … not good, because a 1024 wide image would be available.
@1116 the 1116px version is loaded (makes sense) and displayed 816px wide … (makes no sense, quality-wise)
… and so on ... the 1024px version first shows @1024 yet only 724px wide etc. It would take a viewport of @1324 width to show the 1024px version 1:1.

Thus, an image is never shown in 1:1 resolution, always css-downsized (=degraded?) and often requiring more data transfer than neccessary.

Below-SFX
Below the breakpoint of @768, the padding is zero and the image is showing in 1:1-ratio regarding viewport. However, the image also laps over the container borders, which looks … not good.

--

Hi Arlind,

thanks for coming back on the issue and thanks for the suggestion.

> One thing that I don't understand is how you have incorporated "Carousel" item type inside "Fullscreen portfolio" view?!

We didn't do that ... I appologize for not being more clear. I had written, that in the beginning we chose Kalium for the cool Fullscreen View optics, yet then had to switch to Carousel view, because that view features the same cool item description panel plus the option to control the background for every image we display. In Fullscreen view, the image IS the background, thus it's not possible to apply another background to it. (And just in case: On our site, the carousel looks similar to fullscreen, because the header information and title are hidden. For the description panel to be expanded by default, it took a php manipulation ... yet I think, none of this is touching the issue here).

To reasure my self, i just tested your code in an Fullscreen view item and added the css for the background, that belongs to that image. The latter has of course no effect ...:

http://irgendwas.domainfactory-kunde.at/art/test-fullscreen/

As reference, this is the current view of that image in Carousel view plus background:

http://irgendwas.domainfactory-kunde.at/art/wilde-moehre-fraktal/

(I switched off Coming Soon Mode so you can go there by one click ... hope this doesn't affect my other ticket which is about Coming Soon Mode)

I don't expect the Carousel to be reprogrammed just for me. However, I read in other tickets, that a revision of the Carousel view might well take place at some point not too far from now. Putting the displayed size of the images aside, I think the responsiveness mismatch is indeed an issue ('use large images to fill small spaces').

Until then: is there a possibility to reduce the immense padding (300 px total) of the image holding element (descriptor "slick-list draggable"?) in a viewport-width range of e.g. 880 to 768? That's where things get relatively bad on tablets. If it works, I have no problem to add that code handcrafted to every single one of our approx 100 items.

Thanks for your help in advance.

Best regards,
Wolfgang

Hi Arlind,

I beginn to see, what you actually meant by saying: "... this is not developed within our theme and I am not able to debug the issue because I don't know what is going on there."

I have just set up a local clean install of Kalium on XAMPP, transfered the Theme options from the live site and have to find, that in the carousel view, the item description field in the lower left corner is NOT THERE!

In combination with your statement this indicates, that we have a code manipulation running our live site that I simply was not aware of. Back in October, when we started as complete newbees, we were supported by a web designer that created the basic pages for us. Today it would be different but back then, I probably did not ask the right questions or didn't understand the answers. I have to check back with that person over the weekend to clarify this.

If it turns out to be so, I will document the modification here, just for the record.

In the meantime, please accept my apologies for the confusion I have introduced here. Although I do believe, that my findings remain valid, you are of course free from any support expectations from my side.

Best regards,
Wolfgang

PS. Just in case, if you happen to have the a quick, effortless solution to reducing the 300px padding ... that would just be great.

PPS. 
I put the site back to Coming Soon Mode now.

Hi again,

I now received confirmation, that on our site, significant portions of 'portfolio-single-5.php' were inserted into 'portfolio-single-3.php' to have that elegant description field in that preset, too. The designer who did this actually did a good job and I don't complain to her because at that time I hardly new what a portfolio-item is at all. That's why I had the idea our modified Carousel was originally designed that way.

I apologize for bothering you with that load of information in my original post.

Although it's been quite an effort, my findings are at least of some use to me and I also did find a suitable solution by means of the css-calc function. For example in my custom css' responsive tab under Small Screen I have this:

.slick-list {
 padding: 0px calc(50% - 375px) !important;
}

The "50%" represent half of the viewport width and the "375px" are half of the container width. As a result, an image is now bound to the container width and always fills the space nicely.

Thanks for looking into this and please close the ticket now.

Have a good week @Laborator.

Wolfgang