imgix / imgix.js Goto Github PK

In this pen:
http://codepen.io/miggi/pen/MwbLEK/

I am setting maxWidth and maxHeight, however the values are being ignored, and I'm guessing it is in favor of fitImgTagToContainerHeight. I would expect the max values to be the end all be all.

So the docs are telling me trimcol but imgix.js wants it to be trimcolor.

Who wins?

Right now, we only listen to scroll events on the window for triggering lazy-loads.

We should instead figure out a good way of also listening to scroll events on containers that may obscure images-to-be-lazy-loaded.

Hi,

A minor issue, but still an issue. The version number of 2.2.0 imgix.js returned to server is still 2.1.0. See

Thanks,
Vaclav

Works correctly when fitmode is set to crop, both a height and width will be set. Does not work with fit=fill or clamp.

Testing on this image.

url(https://assets.imgix.net/sandbox/sandboxlogo.ai?bg=fafafa&colorquant=100&fit=fill&fm=png8&ixjsv=1.2.0&page=1&w=326)

Should be setting a height of 300 from the container. Works when passing along fit=crop

Any reason this hasn't been published to npm yet? It works fine in my node project fetching from GitHub, but I'm missing out on npm's versioning features and performance.

right now there is no way to destroy the FluidSet object created by imgix.fluid() this causing memory leaks once the image is removed from the DOM tree.

Please reduce the class size of the unique generated ids for the color palette values to save on file size.

http://migimages.imgix.net/illustration/sketchbooked-012.jpg?auto=format&class=tmp_aHR0cDovL21pZ2ltYWdlcy5pbWdpeC5uZXQvaWxsdXN0cmF0aW9uL3NrZXRjaGJvb2tlZC0wMTIuanBnP2F1dG89Zm9ybWF0JmNyb3A9dG9wJmZpdD1jcm9wJml4anN2PTEuMS4w&colors=16&crop=top&fit=crop&ixjsv=1.1.0&palette=css

There's only one point in the code base that requires the use of Promises, and that's how we compute the colors of a file. We use Promises to do some hacky discovery of these colors

Because palette=json is now available in the API, we should be able to greatly simplify and harden imgix.URL#getColors along with removing the Promise dependency.

Without specifying a token for .fluid(), Imgix returns 400s for WebProxy sources.

Noticed that images that are in fixed position or when their parents are in fixed position imgix does not pick up the image.

Tried with data-src attribute where the element itself was in fixed position and was given a height.

Another situation is when the parent was in fixed position and the element was a img with a position of relative.

In both cases the imgix.js would not detect the images.

Hello imgix.js

With React, I am using imgix to display a background photo in this way

<div
  className="photo imgix-fluid"
  data-src={"https:" + image + "?auto=format&fit=clamp&crop=entropy"}
  />

with the class

.photo {
  background-position: 50% 50%;
  background-size: cover;
} 

The page loads fully, but without the images. The images then load when I resize the viewport by 1px+.

I believe this is due to conflicts between the virtual DOM of React & imgix writing to the DOM.

Any ideas?

I'm running into the problem where Imgix isn't converting the data-src url to src. I think it's because I'm using angular. Any idea how to integrate? I see you have a React library but not one for Angular :)

There are some console.log/warn statements throughout the code that should never be fired in production without ensuring the console exists or defining a noop or something in place of it.

console isn't defined in IE <= 9 unless it's actually open at the time: http://caniuse.com/#search=console

This is problematic when there are other params that imgix doesn't recognize or a new param like ch

I'd like to use imgix in our app and generate secure urls so that users don't tamper with the image url. Maybe I missed it but I don't see anything about secure URLs on the client js library. I can see how we generate that on the admin side but I will need to generate them on the fly in the application.

Any ideas?

Trying to get to the bottom of some scroll jank I noticed that imgix.js library spends a lot of time processing during scroll even after all images have been loaded.

We have since increased our throttle timeout from the default 200ms to 2000ms, which has decreased the amount of time spent in urlParser.

http://stackoverflow.com/questions/30444716/how-to-apply-imgix-js-on-command

$(document).ready(function () {
    var imgixOptions = {
        updateOnResizeDown : true,
        updateOnPinchZoom : true,
        fitImgTagToContainerWidth: true,
        fitImgTagToContainerHeight: true,
        autoInsertCSSBestPractices: true,
        pixelStep : 5
    };

    imgix.onready(function() {
        imgix.fluid(imgixOptions);
    });
});

This works as expected on dom ready however some pieces of my site load dynamically using AJAX.

How can I trigger the imgix-js library to load the images the way it does on dom ready?

Using an image with imgix-fluid applied ignores fit=facearea and sets it back to fit=crop.

So a little background, we want to be able to hide on element and show another element for a test, but using a display: none on the original element, prevents the imgix.js from applying the fluid image for that element. As a result, when that element is shown, it doesn't have the actual image attached.

Resizing the window forces the call to get the image, but I don't see any documentation to force a "refresh", or anything to have it show after being display: none. Our current workaround is to have it be height 0 and visibility hidden, but that seems like a bad hack.

Any input on this would be great! Here's a gif to illustrate:

I'm using Meteor JS which is dynamically changing the value of the data-src attribute of my image container. My problem is that imgix isn't picking up the changes. Even if I re-run imgix.fluid(); after changing the data-src, the src attribute isn't updated.

It works fine if I directly set the src attribute, but I would like to use imgix.fluid();.

For some of our images, imgix is requesting an image with a height but not a width, which is resulting in very large images, in some cases larger than the original.

I haven't yet been able to reduce what I'm working with into a contained example but could you point me to either documentation or the source code of interest where the query strings are being calculated?

Thanks.

Right now, because we proxy image-loading in the imgix.setElementImageAfterLoad method, we're not respecting the crossorigin attribute on images. This can result in duplicate requests when the "cached" image is applied to the <img/> element.

We have an old user generated image that has a (3) in the filename. Why? No idea haha (we've since taken to renaming images so this doesn't happen, but we're still left with older images that potentially have weird characters in them).

If we're using that image as a background image, the parentheses break the CSS attribute, because it escapes the style early:

<div style="background-image: url(https://images.unsplash.com/some-photo(3)-something-else);"></div>

So to fix it, we could wrap the background-image style attribute in parentheses but that seems to break the imgix.js getRawBackgroundImage regex.

You can see the specific image here: https://unsplash.com/photos/4uCSqP5OKiI (it's broken)

Any way we could update the regex to account for parentheses?

Thanks.

http://codepen.io/anon/pen/MazvMB

When you move from a dpr1 screen to a dpr 2 screen and trigger a new image via resize, you get the correct dpr 2 value being appended. When moving back to a dpr 1 screen from the dpr 2 screen, it remains a dpr2 value. See attached codepen. This relates directly to ticket #4123 in zendesk.

In Safari I'm seeing some weird behavior where fluid is creating two requests to Imgix for each image. One for the "preload" and one when the target element src is updated. It doesn't always happen, it appears tied to caching in some capacity.

The callback is fired once the "preload" image onload occurs, but in the scenario I'm describing the image isn't actually done loading at this point.

Boiling it down – the onload callback fires too early in some cases in Safari.

Here's a fiddle that should demonstrate the Safari behavior:
https://jsfiddle.net/6vtr8bjg/

As far as I can tell, testing that artifact is not part of the current CI configuration.

There appears to be a bit of lag in response to the lazy load behavior. Even setting the offset for activation as the entire height of the container, there is a degree of lag in response to the loading of those images.

Update: debounce should be set to 1, or some other faster value by default. It's causing the lag with the default implementation, making it feel unresponsive.

http://codepen.io/miggi/pen/QwejGq

Your md5 implementation leaks as a AMD module when trying to reference imgix with Require.js, which was unexpected. Do you have any plans to make this project AMD compatible?

NPM still has v1.0.17, any chance you could push the latest (currently 1.0.21) to NPM when you get a chance? Thanks!

I can't think of a situation where this is needed in a distributed package of imgix.js. (We shouldn't be including any console.log calls, and we currently are not.)

Does imgix.js offer the ability preview and crop/resize/etc. an image before it's uploaded? If so, can you point me to an example?

https://github.com/imgix/imgix.js/blob/master/dist/imgix.js#L2318

You can see the effect of this at: https://maker.me/sarahmarino. The 400 bad request from imgix is due to the s param being stripped.

were using imgix fluid with default settings and the following overwritten settings:
imgix.fluid({ "fluidClass": "responsive-image", "lazyLoad": true });

Fluid uses the height of the parent container of an image tag to calculate the width/height of itself.
In my opinion this is a wrong behavior. In our case this causes the image to be extremly large since the parent container is much more bigger than the image tag itself.

Have a look at src/fluid.js on line 152 the parent element is used if the current element is an image tag.
elemSize = imgix.helpers.calculateElementSize(imgix.isImageElement(elem) ? elem.parentNode : elem),

If I negotiate this condition everything is working well with the width/height detection.
elemSize = imgix.helpers.calculateElementSize(!imgix.isImageElement(elem) ? elem.parentNode : elem),

Were the last two releases tagged incorrectly?

bower lists these releases:

  - 1.0.18
  - 1.0.17
  - 1.0.16
  - 1.0.15
  - 1.0.14
  - 1.0.13
  - 1.0.12
  - 1.0.11
  - 1.0.10
  - 1.0.9
  - 1.0.8
  - 1.0.7
  - 1.0.6
  - 1.0.5
  - 1.0.4
  - 1.0.3
  - 1.0.2
  - 1.0.1
  - 1.0.0
  - 0.1.20
  - 0.1.19

Note the last two.

bower.json lists 1.0.20 as the current release.

@jacktasia is it possible that the last two releases were tagged as 0.1.19 and 0.1.20 instead of 1.0.19 and 1.0.20?

Having image parameters pegged to a specific fit dimension such as fitImgTagToContainerHeight or fitImgTagToContainerWidth. It would be nice to pass in a desired image ratio, i.e. 4/3 or 16/9 so that images tied to that fluid object can maintain that ratio no matter what. Currently, this can be accomplished using onChangeParamOverride to manually set the width or height.

Example Here:
http://codepen.io/miggi/pen/CGnKm

When the container of an image is set to display:none and the page is resized, it causes a (potentially large) request of the image set to the width of the window.

Steps to recreate:

1. Enable imgix.js on an <img> tag
2. Set display:none to container after image has been loaded in.
3. Resize page and inspect element to see the large width imgix request.

Test here by uncommenting the display:none in .default class.
http://codepen.io/miggi/pen/CGnKm

Question: the URL.autoUpdateImg method refers to a change in the image URL, but it's not clear how I can update the URL of an instance.

In my case I have a single image element for which I'm dynamically setting the src. I'm trying to automatically generate and apply a imgix URL with my desired params whenever I change the source. If I simply update the attribute, the URL is overwritten. I also tried redefining the urlParts.baseUrl property on the instance — same outcome.

My code looks like this:

if (self.imgixPreview) {
  self.$previewElement.attr('src', imgixPath(previewImage.src));
} else {
  self.imgixPreview = new imgix.URL(imgixPath(previewImage.src), {
    q: 90
  });
  self.imgixPreview.attachImageTo('.photos__preview');
  self.imgixPreview.autoUpdateImg('.photos__preview');
}

Currently, we're using the imgix library to build URLs. The images are coming back in the correct size, but for some reason the browser thinks the image is only 1x1 Natural when I hover over the link.

Additionally: this only happens on some of our computers.

Any thoughts?

If a url has a port, the port is not included when getUrl is called.

imageUrl = new imgix.URL('http://localhost:5000/asdf')
imageUrl.getUrl() /* Returns http://localhost/asdf */

I would expect the port to be unchanged.

This will trigger with default images that are not served up through imgix but are being lazy loaded with imgix.js.

Could you add in the UMD pattern to allow this to load with RequireJS or other loaders?

When loading a page via HTTPS, and an image "data-src" attribute set without a protocol, (e.g. //example.imgix.net/main-image.png), the image should be loaded with the proper protocol.

Instead, I'm seeing content always loaded via HTTP even from HTTPS pages.

Expected Behavior:

Setting ignoreDPR to "true" should prohibit the dpr parameter from being set.

Currently, this does not appear to be the case. Relevant ticket: https://imgix1.zendesk.com/agent/tickets/5774

In some cases, we may not want to server higher DPR images, but there is no way to turn this off with .fluid(). Would welcome an option to force DPR settings to stay at 1.

Looks like this is due to a missing config.js file.

➜  imgix.js git:(master) ✗ grunt test
Running "test" task
Warning: 

config.js does not exist. Required for tests! (signing)
 Use --force to continue.

Aborted due to warnings.


Execution Time (2015-08-31 23:08:19 UTC)
loading tasks  226ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 97%
test             5ms  ▇▇▇▇ 2%
Total 232ms

I'm seeing an issue where imgix-fluid images sometimes don't appear when a page is loaded. I thought this might be an issue with my implementation, but I experienced the same thing on both imgix examples:

https://www.imgix.com/js-examples/imgix-img.html
https://www.imgix.com/js-examples/imgix-bg.html

If I resize the screen, then the images load. Behavior is not consistent - sometimes the images load, sometimes not. Using Chrome 50.0.

It is impossible to use this library in browserify without a main script specified in the package.json

Seems like no matter what you set, the fitImgTagToContainerWidth and fitImgTagToContainerHeight parameters of imgix.fluid() will override the fit param of the current URL.

The docs mention that polyfills are for IE8, but I see a Promise polyfill. Due to that at least, am I correct in assuming I need polyfills enabled for my build if I want to support IE at all vs just for IE8?

Also, is onready needed at all if you place imgix.js or at least the initialization code, at the end of the body past all images?

I've got a responsive site, and have a case where a particular section is hidden for mobile and shown for desktop. Using imgix.js for the hidden section requests the maximum possible size for those images. :(

I've got <img class="imgix-fluid" data-src="{{image.source}}"> and using the following options;

var imgixOptions = {
  pixelStep: 50,
  onChangeParamOverride: function (w, h, o) {
    return {fit: 'crop'};
  }
};

My image source is dynamically generated ({{image.source}}), and may already contain a query string, so I can't easily just add ?fit=crop to the data-src attribute. The problem that this creates is that the image originally loads with a huge height set, and no width; http://path.to/my-image.png?ixjsv=2.1.0&h=1250, which means our users are getting hit with large file sizes right at first. Subsequent image loads seem more predictable, but it would be nice if there was a way to set fit=crop without needing to force it on to the end of the source image URL.