Blog

About a year ago we used a brilliant plugin Adaptive Backgrounds (http://briangonzalez.github.io/jquery.adaptive-backgrounds.js/) on one of our projects – OceanWide Expeditions (http://www.oceanwide-expeditions.com/)

Site’s header on pages with hero images is semi-opaque. The script adds slight colored gradient so the page has nicer look and better header links readibility.

It was a great experience to use Adaptive Images on a container with background-image property. But with time past we needed to provide support for <picture> element.

Plugin didn’t support this element, as was searching only for background-image property. The other way it assumes that we have <img> element.

There’s no sense to add “background-image” property to <picture>, as we add one more useless big (remember it is a background for hero image) request on our page.

So, I read a bit further about <picture> , and how it deals with its <img> children.

Adaptive Images is based on RGBaster plugin, that takes <img> or full image URL as argument.

So we had a chance to use it with <picture>. How do we get image from <picture> element?

Its child <img> has an attribute currentSrc for active image from your <source> set. This property is not supported in Safari and IE (https://developer.mozilla.org/en/docs/Web/API/HTMLImageElement#Browser_compatibility)

Please, note that https://example.com/trustlogo.jpg should be changed on the real absolute URL of the TrustLogo on your server

Of course I got a few problems.

First, I got the text – “IdAuthority™ Credentials are NOT available for this site”. This is fine for your local server, as no valid domain is supplied to Comodo. The issue appeared on a dev/live sites on client domains as well, and this is not fine, totally.

The reason is in this line of code:

1

TrustLogo("https://example.com/trustlogo.jpg","CL1","none");

Comodo support team quickly replied on the raised ticket that I used wrong certificate type – CL1. They recommended change this to SC2.

Ok, popup now shown (yay!)

Wait, why I see the scrollbars?

Iframe content is wider than iframe itself (weirdo). So CSS/JS hacks won’t work here, and they seem ridiculuos to me to be applied on the out-of-the-box widget. No main site styles collisions here as well.

Luckily, I had a fellow developer in contact who successfully installed TrustLogo on his site – just use SC5 instead of SC2.

@media only screen and (min-resolution:150dpi) and (max-width: @screen-sm),

only screen and (-webkit-min-device-pixel-ratio:1.5) {

height: 100%;

position:absolute;

overflow:hidden;

-webkit-overflow-scrolling:auto;

-webkit-touch-callout:none;

-webkit-user-select:none;

-khtml-user-select:none;

-moz-user-select:none;

-ms-user-select:none;

user-select:none;

-webkit-transform:translateZ(0);

>.page,

>.footer,

>.header{

display:none;

}

.modal {

position:relative;

overflow-y:scroll!important;

-webkit-overflow-scrolling:touch;

-webkit-backface-visibility:hidden;

-webkit-transform:translateZ(0px);

-webkit-transform:translate3d(0,0,0);

-webkit-perspective:1000;

transform:none;

}

}

}

Please, make sure that your modal has class .modal-open when it’s opened.

In my case, I had a modal with the height larger than mobile screen.

So, a pretty nice solution was to make modal full screen.

So that I have no scroll issues when I open modal – it should be always scrolled to top, and the page saved its scroll position when the modal is closed, I added few jQuery lines (as you are using Bootstrap jQuery is OK here):